The more this discussion goes on, the more I worry that Joe Q Public  
programmer isn't going to be able to properly grasp these new rules.

Everyone here is pretty much the creme de la creme of ruby core  
developers and we're all still having troubles get our minds around  
it (or at least I am).

Let me propose a change to the rules that might help clean them up.  
Change rules 3 and 4 to be one rule that reads:

"If functional style calling is used, say foo(1), foo is looked up  
first in the method table of the defining class as a private method.  
If it is not found, normal dispatch occurs."

This change means that no extended lookup is performed to find  
private methods, only the module that defined the current method is  
looked for the new method. This means that no subclasses can call  
superclass private methods, but really thats ok. A subclass probably  
shouldn't be digging in and calling the private methods of it's  
superclass anyway, the method isn't very private then.

This simplifies the implementation picture as well.

Thoughts?

  - Evan

On Jan 23, 2007, at 6:37 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Wed, 24 Jan 2007 11:19:37 +0900, Daniel DeLorme <dan- 
> ml / dan42.com> writes:
>
> |So private and public methods *do* have different namespaces, in
> |a certain way. While you can't have 2 methods with the same name
> |in a given class, the private "chain" is pretty much independant
> |from the public chain.
>
> Yes.
>
> |But the public chain is very much dependant
> |on the private chain:
> |
> |  class A
> |    private
> |    def bar; "A"; end
> |  end
> |  class B < A
> |    def bar; super+"B"; end
> |  end
> |  class C < B
> |    def bar; super+"C"; end
> |  end
> |  C.new.bar #=> "AC"
> |
> |Am I correct in guessing that the super in C#bar would first look
> |in the private method space and find A#bar, skipping B#bar? Or
> |would 'super' have a different mechanism, bypassing private/public
> |visibility?
>
> When the method is public, super looks for its public super.  That is,
> super in C#bar calls B#bar which is public, then super in B#bar tries
> to find a public #bar in B's superclass.  But A#bar is private (and I
> assume there's no public #bar defined in Object either), thus B#bar
> raises NoMethodError.
>
> |Sorry about all the questions. I'll admit that this mixing of
> |private and public methods is unlikely to happen in the real world,
> |but I'm trying to wrap my mind around all the implications of this
> |dispatch model and it's not easy.
>
> You don't have to be feel sorry.  It is a great chance to find a hole
> (or holes) in my idea.
>
> 							matz.
>