Re: state of the Lua nation on resource cleanup

[John Belmonte <john@...>]

On Mon, Feb 16, 2009 at 9:37 PM, David Manura <dm.lua@math2.org> wrote:
> Here, some local variable "on_exit" far away overrides the environment
> variable of the same name in the scope handler block, thereby breaking
> the code.  We'd prefer the "on_exit" inside the scope handler to
> behave more like a lexical.  You might have noticed that my previous
> example that "basically has the same syntax as John's Lua Programming
> Gem #13" avoids the problem by passing the table containing on_exit as
> an argument rather than as an environment.  The problem here may be
> rare, but I think this trade-off of syntax (three less characters)
> over conceptual integrity[3] is not in the style of Lua.  (Well,
> sometimes it is[2], but that could be improved :) )

I don't think I was aware of the pitfall you mention when writing the
gem article, but I make a case for passing in a manager variable on
other grounds (as quoted below).  Putting everything together, I would
use an explicit manager given Lua as it is today.

 "A slightly different design for the scope utility would be to pass
  the manager object to the user's function as an argument.  Besides
  eliminating the complexity of making on_exit and the other
  registration methods appear implicitly within the function, this would
  allow the manager to be passed to utility functions.  For example,
  the allocate_canvas function could take a scope manager as an
  optional argument, and in that case register the canvas cleanup
  code for us.  On the other hand, the explicit manager variable
  makes the user's code more verbose in the simple case, and opens
  the door for confusion should someone try to operate on the
  manager of an already expired scope."