Re: new method dispatch rule (matz' proposal)

Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Tue, 23 Jan 2007 16:13:41 +0900, Charles Oliver Nutter <[e-mail]> writes:
> 
> |> (2) send(:foo) and recv.foo (with receiver method dispatch) only skips
> |>     private methods.
> |>     In current Ruby, if any private method foo are there, raise exception.
> |
> |I assume this is an extension of (1), where if there are private methods
> |they're just ignored, yes?
> 
> Yes.
> 
> |> (3) method dispatch as function like "foo()", introduce new method
> |> search ordering.
> |> 
> |>     1. search *only private methods* in inheritance tree.
> |>     2. search public methods in inheritance tree from CLASS_OF(self).
> |
> |I'm not sure I understand the justification for this. We would now have
> |to have two method caches in any implementations and do two searches for
> |all methods.
> 
> Unless you don't have in-line method cache.
> 
> |Further, it would greatly impact the performance of all
> |public method calls, since there would always be a "private" search in
> |the whole hierarchy first.
> 
> I haven't implemented this yet, so that I can't say it for sure but I
> don't think so.  Because public method calls (with explicit receiver)
> need only one hierarchy search and one method cache.

But for calls that could result in both private and public methods being 
searched, this would still apply. It will require two searches up the 
hierarchy, making it even slower to find the method than it is today.

> 
> | So, if I have:
> |
> |class A; def bar; end; end
> |class B<A; end
> |class C<B; end
> |class D<C; end
> |class E<D; end
> |class F<E; def foo; bar; end; def bar; end; end;
> |
> |F.new.foo would result in a search of classes E, D, C, B, and A for
> |every invocation of bar, finally settling on the bar in F. Further, if
> |now a bar was added in any of those classes or the existing bar in A was
> |made private, my local bar would no longer be invoked. That seems
> |extremely counter intuitive.
> 
> No, it's only for functional style method calls.

Ok, substitute in def foo; bar(); end above, or give bar some 
parameters. To call bar() a full search of the hierarchy must be 
performed for private methods, and then eventually it comes back to the 
bar defined in F. And if the bar defined in A becomes private later on, 
it will be invoked instead. That seems very strange.

> |It also makes it much harder for developers to name methods in their
> |extensions of superclasses because they must always avoid naming a
> |method after a private method somewhere else in the hierarchy. This also
> |causes private changes to those superclasses to leak into child classes;
> |if a developer now decides to add a new private "baz" method to their
> |superclass, and I have been using that name for a public method in my
> |subclass, my version will suddenly stop being called.
> |
> |- Changes to private methods in parent classes should not change the
> |behavior of method dispatch in child classes
> |- Child class implementers should not have to know about internal
> |(private) methods in superclasses when doing their implementation.
> 
> I think understand what you meant here.  And that's the reason for
> rule 4.  By adding rule 4, any methods can not override private
> functions, since private method search starts from the defining class.

But it still means that changing method visibility in the parent will 
affect which methods are called in the child. Rule four is perfectly 
valid for ensuring a method foo calls a private method baz contained in 
the same class, but rule three complicates things by also making child 
classes that call baz hit the same method. I'll try another example

class A
   def foo; bar("A foo"); end
   def bar(x); puts "A bar #{x}"; end
end
class B < A
   def foo; bar("B foo"); end
   def bar(x); puts "B bar #{x}"; end
end

So here, as today, B.new.foo calls B's bar method. Now a change:

class A
   private :bar
end

Now, because of a change in A, B.new.foo calls A's bar. When priority is 
given to private methods in parent clases, parent classes can 
effectively override child classes.

Now what if B's author didn't know about the "bar" method in A. Suddenly 
a release of A comes out with "bar" private, and B's code breaks. Should 
making a method private have the potential to break child classes? The 
most it should do is ensure that A's foo always calls A's bar.

Parent classes should not be able to affect the method search order for 
children by making changes to private methods.

- Charlie