--- "Ara.T.Howard" <Ara.T.Howard / noaa.gov> wrote:

> every single method available at the top level would leave
> it's block
> variables in the top level forever!  after a few method calls
> 'local_variables' would return a list 10,000 items long. 
> they could never be
> gc'd.

If your top-level has uses 10,000 different variable names,
then I think it is safe to say that you are not modularizing
enough.  In my opinion, the executable code (not declarations -
methods, classes, modules, etc) in the top-level should be no
more complex than the code in any other method.

Of course if you used blocks even for you declarations
(define_method, Class.new {...}, Module.new {...}), you'd run
into problems (all non-arg variables would get propagated to
the top-level).  But those also have problems now because you
have to make sure that the variables aren't used already to
really make them local.

Also, if you want the object a variable references to be freed,
you can just assign it to nil.  The object may get GC'd, but
the entry in the variable table won't until it goes out of
scope (never at the top-level).  It'd be nice if it was like
Lua where a non-existant variable is equivalent to a variable
assigned to nil.


> > There are several ways you could treat variables within
> blocks:
> >
> > - local if not in surrounding scope (now in 1.8)
> > - local with no relation to surrounding scope (2.0 args)
> > - local and intialized to same value in surrounding scope
> > - same scope as surrounding scope (2.0 other variables)
> >
> > I think it is hard to pick from these.  You can make an
> argument that any of
> > these are useful.  It would be nice to be able to control
> this more
> > directly, but this may also reduce readability.
> 
> if the aim is to unify lambda and methods then the move must
> be towards local
> vars only no?

Not sure.  Blocks can look like a couple things that have
different scoping:

1. def...end/class...end vs.
define_method(..){...}/Class.new{...}: normal variables in a
"def" method are completely local to the def scope.  They have
no access outside.

2. for-in/while/if/else/etc vs. #each{...}/loop{...}/etc:
variables in built-in loops/conditionals use the same scope as
what is surrounding

The scoping change for blocks looks to be a move to making
blocks to have similar scoping as #2.  Now it is somewhere
between #1 and #2.

Personally, I'd like to see both of these block forms for
dealing with normal variables - local and use the surrounding
scope.  But, for the local case, I'd like those local variables
to be initialized to what they were in the surrouding scope. 
That way you have read-only access to the outside.  Maybe for
the local block you'd also not be able to get a full eval'able
binding - solves the GC issue for those.



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com