From: Robert Klemme <bob.news@...>
Date: 2004-04-15T23:14:10+09:00
Subject: Re: New Local Variable Scope rule


"David Alan Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:m33c75o1oc.fsf@wobblini.net...
> Hi --
>
> ts <decoux@moulon.inra.fr> writes:
>
> > >>>>> "D" == David Alan Black <dblack@wobblini.net> writes:
> >
> > D> That may be what will happen:
> >
> > D>   l = lambda { a = 1 }
> > D>   p a                    # nil (not error)
> >
> >  Well, this is what I've trying to say
> >
> >      l = lambda { a = 1 } # 2.0
> >
> >  is similar to
> >
> >      a = nil
> >      l = lambda { a = 1 } # 1.8
>
> I guess I've been trying to have it be something else because I
> dislike that so much (the 2.0 version).
>
> > D> (Of course, I'm one of the few who think the way block variables
work
> > D> pre-2.0 is fine, but that's another story :-)
> >
> >   1) confuse some persons, which see |a, b| as a declaration rather
than an
> >      assignement
>
> I wish they would just learn it :-)  But of course Matz has decided he
> doesn't like it, so that's that.
>
> >   2) there are really 2 different uses for block-local variable. In an
> >      iterator probably you'll expect the 2.0 behaviour, in a Thread
(or
> >      perhaps a Proc) probably you expect the 1.8 behaviour
>
> That's why I was asking earlier whether this is a further difference
> between Procs and blocks.  For example:
>
>   # 2.0
>   def x
>     pr = Proc.new { a = 1 }
>     l = lambda { b = 1 }
>     # do we have a and b defined here, or just b?
>   end

Why would we have anything defined here although both blocks are not
executed in this example?  Slowly I'm loosing grips here...  A summary was
definitely in order.

I used to be confused, but now I'm not sure anymore.

    robert