Hello--

David A. Black wrote:
> On Tue, 12 Apr 2005, Trans wrote:
> 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.

I don't find the look of it at all ugly, only the asymmetry of that
particular case. But I understand why it must be so.

Also I point out the behavior of calling a private method using self as
the specified reciever: an error. So there is some precedence for
certain distinctions here. But I certainly agree with you, I do not
think it would not be wise to overload it in the manner originally
suggested.

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

That's only one use case actually. Another is fine-grain control of
inheritance --one can direct methods directly to specific parents. But
I agree with your hesitation for the reason of its nonoopiness (funny
word ;) but that's the trade off. I offered the concept of locals to
gain a middle ground in that trade --not quite as powerful, but
maintains some reusability (a very useful reusability for AOP, I might
add).

Hmmm... now that I think about it more in this light it could also be
interesting to actually define methods in this direct notation as well,
and this might lessen the shortcomings.

  class C
    def x
      "C"
    end
  end

  C.new.x  #=> C

  def C#x
    "CX"
  end

  C.new.x  #=> CX

T.