Re: new method dispatch rule (matz' proposal)

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.

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

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

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

							matz.