From: dblack@...
Date: 2002-08-10T14:54:32+09:00
Subject: Re: ambiguity between local variable assignment and writter method

Hi --

On Sat, 10 Aug 2002, Tom Sawyer wrote:

> 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

Isn't it good to have to know when you're calling a method and when
you're assigning to a local variable :-)

>     5. writer methods have an EXCEPTION in their behavior

It's just a constraint, not an exception.  Just as in some situations
you have to use parentheses, in some situations you have to name your
receiver.

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

(At one point you suggested "localvar := x", though I won't argue if
you've reconsidered :-)  Anyway -- with regard to defaulting to writer
methods, rather than to local variables: the problem arises that you
can't know what will be present at a given point in the execution of
the program.  For example (pointless code, but just for illustration):

  class A
    def initialize(n)
      thing = n
      puts "Initializing with argument #{thing}."
    end
  end

  class B < A
    attr_writer :thing
  end

What happens when you now say:

  b = B.new(123)

Does "thing = n", from B's superclass, now suddenly mean
"self.thing = n", rather than assigning to a local variable?
(Obviously part of the picture is that subclasses of A cannot and must
not know anything about the names of local variables in instance
methods of A.)

In other words: the meaning of "thing = n" has to be determined, once
and for all, when it's first encountered; and the only thing it can
definitely be in every single case is a local variable assignment.

(I think this is related to what Dave was saying about subclasses in
response to Rich, though that's in a slightly different context.)


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav