Austin Ziegler wrote:
> On 10/18/05, Trans <transfire / gmail.com> wrote:
> > Austin Ziegler wrote:
> >> On 10/18/05, Sean O'Halpin <sean.ohalpin / gmail.com> wrote:
> >>> On 10/18/05, Eric Mahurin <eric_mahurin / yahoo.com> wrote:
> >>>> But, I kind of still wish we had a syntax where the variables in a
> >>>> block/lambda were local (non-closure) by default.
> >>> Maybe if we say it often enough? ;)
> >> Doubtful. I think to convince matz, real examples would need to be
> >> presented (as an RCR!) as to why this is necessary. IANM, but IMO
> >> theoretical need and wish ain't sufficient.
> > The easist is the old gotcha. Programmer has code (doesn't much matter
> > what it is)
>
> [...]
>
> > And wants to resue the lambda so uses old fashion copy and paste:
> >
> >   class Y
> >     def bar( n )
> >       x = n * 3
> >       l = lambda { |a| x = a**2; x + 1 }
> >       return x + l[3]
> >     end
> >   end
> >
> > Oopsy.
>
> Dumb programmer. This part isn't nearly sufficient to justify a new
> scope or kind of lambda (lambda without closure), IMO. If you want to
> reuse a lambda that you're not passing around, make it a method.

Dumb example. But I wasn't foging for "gold". Surely you can
extrapolate beyond this. Take a class context for instance, used to
define a few methods on a template. Class methods could interfere, etc.

[...]

> This isn't a closure problem. This is a constant lookup problem, and
> Matz has said that this should be fixed moving forward.

It has to do with closures in that the reference to constants is
relative to the given closure. So the current behavior is correct. A
non-closure block will allow the needed alternate behavior.
 
T.