lua-users home
lua-l archive

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


Daniel Silverstone <dsilvers@digital-scurf.org> writes:
>> It's almost trivial to make most code 5.1/5.2 agnostic, and Lua
>> isn't going to drop the changes in 5.2, so where exactly is the
>> benefit in "holding off"...?
>
> I'm well known for doing "unusual" things with my code.  In
> particular I do a lot of function environment related stuff.  I do
> not believe there is a consistent way at the moment to provide "5.1
> standard" setfenv semantics to 5.2 pure Lua code.  I could be wrong,
> but the large amount of discussion surrounding it has confused me,
> and quite honestly worried me.

I dunno what exactly your code does, but in my experience with porting
code to 5.2, almost every use of setfenv I've run across is pretty
simple, only setting the environment of any given function once,
typically not so long after creating it (via load or whatever):

    -- 5.1 code:
    fun = loadfile ("xyz")
    ...
    env = make_my_env ()
    ...
    setfenv (fun, env)

Which for portability to 5.2 (maintaining compatibility with 5.1) can
be rewritten to:

    -- 5.1 and 5.2 code:
    env = make_my_env ()
    ...
    fun = loadfile ("xyz", nil, env)  -- ENV argument ignored by 5.1
    ...
    if setfenv then
       setfenv (fun, env)  -- only on 5.1
    end

Sometimes I've had cases where the function creation, env creation,
and setfenv are in different functions, widely separated in the
source, but still essentially follow that pattern.  The main issue
I've had which required a bit of code restructuring was making sure
that the environment is created early enough to be available at
load-time.

> Perhaps you can point me at a "porting to 5.2" document I could use
> to help me understand the transition?

Sorry, don't know of anything offhand.

-miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche