lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Will getfenv/setfenv still be supported on userdata objects?  I use
this feature in the lua-ev[1] extension so that objects are properly
garbage collected.

For example, the "watcher" C structures need to reference a lua
callback function, therefore we want the lua callback function to be
garbage collected when the C "watcher" structure (aka userdata) is
garbage collected.  Using the userdata fenv has proven to be the best
way to accomplish this.

Thanks,
-Brian

[1] http://github.com/brimworks/lua-ev

On Tue, Jan 12, 2010 at 7:25 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> I will try to answer the sereval requests for our rationale for the
> removal of setfenv/getfenv.
>
> The main motivation was that, in our view, setfenv/getfenv was too
> dynamic.  Basically, if function A can call function B, it can also
> change the environment of B. If function A calls B, B can change the
> environment of A. In other words, almost anything can change the
> environment of anything.
>
> We tried to restrict such uses. Basically, if you create a new function,
> you can set its environment. Otherwise, the function itself should be
> responsible for its own environment (using lexical environments).
>
> Most uses easily fit this setting. Others may need extra work. For
> instance, more than one user talked about loading a piece of code once
> and running it whith different environments. I may be wrong, but
> I think the following code does it (suggested by lhf):
>
>  code = "string with the code to be loaded"
>  f = loadstring("in ... do " .. code .. " end")
>
> Now, each time you call 'f', the first argument is the environment where
> the code will run. (Of course, if the original code uses the vararg, it
> should be corrected to slip this extra first argument.)
>
> We are not sure whether everything that was doable is still doable, but
> the main point is that we were not sure whether everything that was
> doable should be doable.
>
> -- Roberto
>



-- 
Brian Maher >> Glory to God <<