Re: new method dispatch rule (matz' proposal)

On Tue, 23 Jan 2007, James Edward Gray II wrote:

> On Jan 23, 2007, at 7:41 AM, Yukihiro Matsumoto wrote:
> 
> > Hi,
> > 
> > In message "Re: new method dispatch rule (matz' proposal)"
> >    on Tue, 23 Jan 2007 19:56:11 +0900, Daniel DeLorme <[e-mail]>
> > writes:
> > 
> > |> (4) (unconfirmed) private method dispatch searches from caller method
> > class.
> > |
> > |Do I understand correctly that:
> > |  class A
> > |    def foo; bar; end
> > |    private
> > |    def bar; "A"; end
> > |  end
> > |  class B < A
> > |    private
> > |    def bar; "B"; end
> > |  end
> > |  B.new.foo #=> "A"
> > |
> > |So the only way to do polymorphism would be through public methods?
> > 
> > Yes.
> 
> That seems like a positive change to me.

Interesting.  Doesn't this mean more care will be needed to develop
private interfaces prior to them becoming public?  I was looking at
"Refactoring" again last night, and this talks about the benefits of
publishing interfaces as late as possible, because interface may
change as you refactor, and provided it is not published then that
doesn't matter.  With rdoc one can suppress publication, but even so
I fail to see the benefit of two inheritance models for the same
object.  Changing a method from private to public will change the
search "path" for that method.

Also, to get the redefined bar method in a call to foo in the above
example, class B would have to have its own implementation of foo.
I see this as leading to code duplication, which breaks DRY.

What is the underlying idea that makes this approach uniform and
cohesive?  If I could see that I'd be happier about this change.
That, and the DRY point, suggest I have misunderstood this whole
thing, because Ruby doesn't make things more difficult.  
Sorry for being slow on the uptake.
> 
> James Edward Gray II
> 
        Hugh