From: Tom Sawyer <transami@...>
Date: 2002-08-10T14:17:05+09:00
Subject: Re: ambiguity between local variable assignment and writter method

On Fri, 2002-08-09 at 22:50, dblack@candle.superlink.net wrote:

> Cons:
> 
>   1. you have to type what feels like an "extra" "self".

    2. you have to know when you need the extra self and when you don't

    3. code looks spotty with self used sometimes but not others

    4. code is longer

    5. writer methods have an EXCEPTION in their behavior
 
> Pros:
> 
>   1. in Ruby, you get to leave "self" off a lot, so having it not be
>      100% of the time isn't so bad.  One can think of it as: you have
>      to specify the receiver, except where it's clear without it, and
>      it's clear without it much of the time (which I like).

counter-argument: "isn't so bad" isn't good enough, unless there are no
reasonable alternatives. if there is a good alternative, for all of the
time, why not take it?

>   2. The "self.thing = x" form is, ultimately, completely consistent
>      with Ruby syntax in general; we're not being asked to do
>      something anomalous.  Even though this is a special case, it's
>      not special syntax.  It's just disambiguation.

counter-argument: don't really see this as a PRO. you are right, it is
consistent and you can use self all you want, whether you need to or
not. that's fine. i'm certainly not suggesting that we throw out self.
self is very essential.

>   3. It's one of the rites of passage into Ruby to have to master
>      this, sort of like realizing that #{...} can interpolate more
>      than just single variables :-)

counter-argument: such can never be a PRO, in fact, no offense, but it
smacks of ruby righteousness. it also flys in the face of POLS. you
don't judge a thing "good" b/c it is difficult and overcoming the
difficulty gives you a sense of accomplishment. if that were the case we
should all be coding in machine code. :-)
 
> Follow-up to #2: for that reason (i.e., providing a receiver is normal
> Ruby syntax), I'd rather it were left like this than that any new
> construct were added to avoid it.  That seems like a potentially
> never-ending spiral: define syntax; where it's ambiguous, instead of
> requiring strict/explicit usage *within* the syntax, introduce a new
> construct; eventually, something will crop up with the new construct
> that requires disambiguation; create new syntax for that... etc.

i agree. i don't want to add any new constructs. and i don't think we
need to in order to clear up this inconsistency. simply giving
precedence to writer methods would do it.

-- 
~transami