From: ara.t.howard@...
Date: 2007-01-20T07:41:21+09:00
Subject: Re: local variable assertion

On Sat, 20 Jan 2007 dflanagan@gmail.com wrote:

>
> It changes it because you fail-fast with a NameError rather than possibly
> introducing a bug that may not be near to the source of the error.
>

but you could fail faster?  by the time you decide the names you will use
you no longer need 'local'?

>
>> 'x' defined 20 lines up, you don't notice and introduce a bug.  in order to
>> prevent this you are advocating this
>>
>>    local :x do
>>      data.each { |x| x*x}
>>    end
>>
>> so a re-def of x will raise an error.  at first glance that seems ok.
>> consider this however: one must __know_in_advance__ which vars to declare
>> local and which not.
>
> The local vars are the ones that you want to be local in the block.  I
> think this is always easy.  And, when you have to cut-and-paste, you
> copy the entire local block, so that the protection it gives you
> travels with the code.

i think this is misleading. take your example:  if cut and paste this

   local :x do
     data.map!{|x| x ** 2}
   end

somewhere else i'm safe not only if x hasn't been used in the new scope, but
also if data hasn't, or is has, but it's the correct value.  the thing is you
are not going paste that code without knowing where 'data' is coming from: you
haven't eliminated the problem or even really reduced it since you __still__
must ensure your current scope isn't too big you wrap your brain around:
you've got to know where data is coming from and it's going to come from
exactly the same place 'x' is - the current scope, which you must understand
in it's entirety in order to use 'data' properly in the new cut-and-pasted
context...

the entire concept that a programming contruct can make it safe to cut and
paste code is really quite a strech...

your local impl is __still__ a mixed scope like any other block in ruby and
therefore suffers exactly the same issues: in the above you could easily
clobber a local version of 'data', especially if you cut and pasted it into a
scope where it's origin was unknown.

in summary, i don't think one can possibly solve the issues of mixed scoping
of blocks with a method that takes a mixedly scoped block!  ;-)

in addtion, the local impl requires __twice__ as many definitions of local
variables and we all know where that goes: more lines almost never equals
fewer bugs - that's the d.r.y principle that's so big in the ruby community.

in anycase i think matz's block-local vars, due for ruby 1.9 address the
largest issues with block scoping already.

cheers.

-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama