From: Brian Candler <B.Candler@...>
Date: 2003-02-01T23:09:55+09:00
Subject: Re: local variables, blocks & self ambiguity (was Local variables & blocks)

> eeee.....well, they wouldn't be local then :) on the other hand is self became
> associated to the def, then other problems would arise. okay, so that was
> actually a dumb idea. :0o

There's another thing. Presumably you would like to resolve the "local
variable versus attribute writer" ambiguity:

    leftvol = rightvol = 0             # local variable assignments
    self.leftvol = self.rightvol = 0   # method calls leftvol=, rightvol=

Actually, this could be solved in the current scenario, simply by searching
for a 'leftvol=' method before falling back to a local variable assignment.

The efficiency cost, however, would be unbearable. Imagine the simple
statement:

    x = 0

which at the moment, can be infered (at compile time) to be an assignment to
a local variable. If this could not be assumed to be a local variable, then
a complete method search would have to be done (at run time) every time this
statement is executed - all the way up the class hierarchy. Methods can be
added dynamically to an object at any time, so there's no way to cache this
information.

Furthermore, consider cases like this:

    if ... some condition
       ...
       flag = true
    end

    flag && do_something

In the current model, 'flag' is always available at the final statement, as
a known local variable, with value 'nil' if not assigned. If it were
dynamically created, then the final statement might crash altogether. If
there were any chance of this happening, you would have to add 'flag=nil' at
the top of the code, effectively a declaration of the variable.

You could of course resolve this by making local variables have a distinct
syntax from method calls - say $variable. Oops, we wouldn't want that :-)

Cheers,

Brian.