From: Hugh Sasse <hgs@...>
Date: 2007-01-24T00:22:54+09:00
Subject: Re: new method dispatch rule (matz' proposal)

On Tue, 23 Jan 2007, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Tue, 23 Jan 2007 23:26:17 +0900, Hugh Sasse <hgs@dmu.ac.uk> writes:
> 
> |Interesting.  Doesn't this mean more care will be needed to develop
> |private interfaces prior to them becoming public?
> 
> I don't think so.  Polymorphism wouldn't happen for private methods by
> the new look-up scheme, so that we need less care for method name
> conflict.  We have to care only for methods tried to share same name
> in the same class/module.
> 
> |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.
> 
> I am not sure what you meant.  Do you want private AND overridable

Aha!  I see what you mean now.  For B to 'know' that bar must be 
overridden breaks encapsulation anyway.  So the unifying idea I
sought is "proper privacy".   

What I meant was that since foo calls A's private method bar, when B
redefines bar, in order to get B#foo to call B's bar, one needs a
re-definition of foo. Otherwise B#foo will always call A#bar.  Thus
one has to write a foo method for B which is a textual copy of A's
foo method (in order to get the *same* behaviour, but calling B#bar).
That seems to be duplicated code, rather than re-use.  But I can 
now squash my argument, because such duplication is only known to 
be duplication if encapsulation is broken, invading A's privacy.

However, I can see that this proposal means defining private methods
in a subclass won't break existing methods of parent classes, without
the child class having to avoid name clashes.  And that is a
simplification.

> methods?  I am vaguely thinking of changing protected for that

Yes, that would override [:-)] my remaining discomfort.

> purpose (or introducing a new visibility).

> 
> 							matz.
> 

Thank you.  I think you've helped me argue myself round to your
position :-)

        Hugh