Hi --

On Sun, 31 Jul 2005, Trans wrote:

>
> David A. Black wrote:
>>
>> That would essentially do away with the notion of a local variable.  I
>> think it's valuable to have them -- really quarantined "scratchpad"
>> things that just don't overlap between scopes.  Writing things that
>> depend on local variable names from other scopes is pretty fragile.
>>
>
> Would it? Hmm.. I guess I was thinking that if you assigned a vairable
> in the current scope it would get locked into that scope, and hence be
> just as local as it ever was (kind of like method vs. local var).
>
>  foo = 1
>  p foo
>  def x
>    foo = 2
>    p foo
>  end
>  x
>  p foo
>
> _produces_
>
>  1
>  2
>  1
>
> To hang on to the outerscope one would have to "replace" foo instead of
> assign it. Tough I suppose that'd require a general ability to use
> #replace on anything (and probably a replace operator like ":=").
> Nonetheless, doesn't that preserve local vars and yet "open-up" the
> scopes? (Mind you I'm not neccessarily suggesting this would even be
> possibile given how Ruby is implemented, but the idea in general seems
> intriging.)

It's fragile because it means you're coupling things that are in
different scopes.  You might, for example, want to refactor part of
your program (put a class definition in another file, or whatever),
and you'd have to keep track of these "local" variables because
someone, somewhere, might have used your "local" variable in another
scope with ::var or whatever.

Keep in mind that with Class#new, class_eval, define_method, closures,
and other such tools, you can do a fair amount of scope-capturing
already.  I think part of the point of the class and def keywords is
to seal off the scope of local variables.


David

-- 
David A. Black
dblack / wobblini.net