From: Leo Razoumov <see_signature@127.0.0.1>
Date: 2001-03-09T05:10:02+09:00
Subject: [ruby-talk:12296] Re: FEATURE REQUEST: 'my' local variables

>>>>> "FF" == Furio Filoseta <ffiloseta@cantv.net> writes:
    FF> I am sure you see this as useful, but I honestly can岐 grasp why
    FF> on earth 
    FF> one would one to deliberately introduce one more worry. I mean, if I knew
    FF> the var would be local, I would name it in a related way, Xl for example.
    FF> Then again, this may only be a reflection of my own lack of proficiency. Can
    FF> you show me a case in which it would be indispensable to have such a
    FF> construct ?|

    FF> FRF

I am not sure that the respondents got my point right. Probably I was not precise
enough. Ruby has already ways to distinguish between global, local, instance and
class variables in a very verbose and useful way.
However, there is no way to distinguish two local variables if the scope of one
encloses the scope of another (unless their names are different).

x = 0
{ 
  x = 7 # still the same old local 'x' from the outer scope
}

If a project has more than one developer or a developer is maintaining a project
written by someone else and under the time pressure this Ruby scoping rule can
be a source of very nasty and hard to catch bugs.

Many people used to write 

for i in 0..10 
.....
end
i # -> 10  # set by the for loop


Suddenly your program goes crazy because someone already introduced local 'i' in
one of the enclosing scopes might be 200 lines earlier and it holds some other
magic number like 12345. Now my innocently looking 'for' loop resets the value
of 'i' to 10 which is a BUG.

At present a responsible Ruby programmer must familiarize himself with all the
names of all local variables in all the enclosing scopes to avoid conflicts with
his own locals.

Please, explain me why such a minimalistic language as Scheme does have 
(let (...)) construct to create scoped locals while such a rich language as
Ruby does not.

If you do not like name 'my' call it anything:
'local', '__my__', '__local__'. 

A programmer should have full control of the block of code (scope) if he needs
to. If I need to do a quick patch to an existing (and unfriendly) code-base I
should have a way to be sure that at least my local variables do not clash with
somebody's else. And I should be able to do so without making a list of all
locals in all enclosing scopes.

thanks,
-- Leo