Re: new method dispatch rule (matz' proposal)

Hi,

In message "Re: new method dispatch rule (matz' proposal)"
    on Wed, 24 Jan 2007 03:18:26 +0900, Charles Oliver Nutter <[e-mail]> writes:

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

For functional style call, yes.  The increasing costs are

  * private method search that start from defining class to Kernel
  * two method cache check unless we use in-line method cache

for each functional style calls.  If cache works properly the former
cost will become nothing.  The latter is unavoidable, but its cost is
a few instructions per each invocations so that - in my opinion - it
won't be a performance factor neither.  Or you can optimize more
aggressively, since private methods are not overridden under the new
behavior.  You can call them directly without any dispatching using
in-line cache.  It may make method calls even faster than now.

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

That may be strange in the corner cases.  But it's useful for most
cases.

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

I understand the principles that you care.  But visibility are not
that fragile for most of the cases.  Is there any way that addresses
name conflict issue AND has no strange visibility issue?

							matz.