Re: new method dispatch rule (matz' proposal)

It's late for me here, so I have just brief comments below...

SASADA Koichi wrote:
> Hi,
> 
> This post is translation of [ruby-dev:30107], a new method dispatch rule
> proposed by Matz.  I post it because I want to discuss about it widely.
> 
> 
> This change is to clarify "private" feature.
> 
> (1) send(:foo) accesses only public methods.

This seems fine.

> (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?

> (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. 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. 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.

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.

> (4) (unconfirmed) private method dispatch searches from caller method class.

If the goal of (3) is to ensure that private methods invoked within the
same class are always dispatched to the same method, (4) seems to solve
this problem very neatly. I do not see that any utility of (3) would
outweigh the confusion caused by method dispatch changing due to
addition/modification of private methods in parent classes.

- Charlie