dblack / candle.superlink.net wrote:

>> >> >> Isn't it good to have to know when you're calling a method and when
>> >> >> you're assigning to a local variable :-)
> 
> I didn't mean that as an anti o.member = 'x' argument though :-)  It
> was in response to Tom's having listed needing to know when to write
> "self." among the cons of the variable/method ambiguity.  My point was
> just that one already knows one is calling a method; there's no extra
> knowledge involved.

I know I was putting it in a different context.  I didn't mean to imply you 
were making the same point as me.  :)

>> I understand the motive of member=(), though.  Since the interface of a
>> class consists only of methods, o.member = 'x' has no meaning, so why not
>> make that a method too?  The problem is when it's used inside a class,
>> when
>> you can omit the "o.", and a gotcha arises from potential ambiguity.  I
>> wonder if simply leaving "o.member = 'x'" as illegal ruby would've been
>> better.
> 
> I would describe it in a different sequence:  it's used inside a
> class, you *can't* omit the 'o', you write the 'o', there's no
> ambiguity :-)

I was considering the motive from a language design point of view.  As in, 
"I'm making a funky new flawless language, and I've just saved the world 
from the evil of public data members.  Now what've we got to build on?"  Or 
maybe that was never part of the design process...

> I think one thing that needs to be taken into account is how little
> impact this actually has on code -- in comparison to the impact there
> would be, visually, if every local variable assignment looked
> different, or if every "obj.thing = x" became something else.

Not sure if I get what you mean by "impact" since I was looking at it as a 
retrospective curiosity, not as a proposed language change.  If set_* 
methods would've been the norm, I don't think I could describe it as any 
"impact" whatsoever, since it's a pretty normal thing to do (looking at 
other OO languages).  member= methods in contrast are unexpected; an 
"impact"; a protrusion on an otherwise pretty flat, consistant landscape.  
(Not that that's necessarily bad; protrusion == innovation.)