Hi --

On Tue, 12 Apr 2005, Trans wrote:

>
> Avdi Grimm wrote:
>> Actually, in my mind applying the principle of least astonishment
>> would lead to expecting store and self.store to have identical
>> behaviour.  I would expect to have to use something like super.store
>> or A::store in order to specify that I want the superclass version of
>> store.
>
> I have to agree with you. While making a distinction around the use of
> self.x verses x seems reasonable to some degree (after all they are
> written differently), the old ambiguity of x= raises it's ugly head.

They're written differently, but the whole self.x = y thing is just
the price we pay for, in every other situation, being allowed to drop
'self' as the receiver.  It keeps things simple and clean, overall
(and it's really not *that* ugly; it's just a receiver :-) So I
wouldn't want to look at that as a rationale for overloading it, which
would make it less simple.

> To
> refresh, x= would be interpreted as a local variable assignment and not
> a method call, thus requiring the use of self.x= instead. B/c of this
> x= and self.x= must remain equivalent.
>
> But lets say we do adopt a differnt syntax as you suggest. Of the
> options I think David's suggestion of M#x is the most obvious since
> that's the standard way to refer to a method already. But even this has
> problems in that it puts some limits on reusability. Consider:
>
>  module M
>    def x ; 1 ; end
>    def y1 ; M#x ; end
>    def y2 ; M#x ; end
>    def y3 ; M#x ; end
>    # etc.
>  end
>
> Perhaps originally it wasn't intended to be used otherwise, but if we
> later wanted to create a variation of M with an altered #x, we'd then
> have a problem b/c ordinary code like:
>
>  class N
>    include M
>    def x ; 2 ; end
>  end
>
>  n = N.new
>  n.y1  #=> 1
>  n.y2  #=> 1
>  n.y3  #=> 1
>
> won't work. To overcome we'd actually have to redefine #y1, #y2, #y3
> .... and so on. Not good.

But that's the whole purpose of the thing (whether it's M#x or self.x
or whatever) -- to constrain the nested method call (the call to #x
inside M#y1 etc.) and protect it from the redefinition of #x.  I'm not
convinced of the merits of it (I continue to tend to think that anyone
subclassing a class should know the names of that class's methods, and
not accidentally override them), but the idea is specifically to
provide that protection.


David

-- 
David A. Black
dblack / wobblini.net