[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Global modification policy in Penlight
- From: Thijs Schreijer <thijs@...>
- Date: Tue, 30 Apr 2013 10:08:34 +0000
> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of steve donovan
> Sent: dinsdag 30 april 2013 11:07
> To: Lua mailing list
> Subject: Global modification policy in Penlight
>
> Hi all,
> Just want to gauge feeling on this issue. Currently, pl.utils acts as a
> 5.1/5.2 compatibility layer, and so it alters the global state. Let my
> friend lglob express the situation, running in 5.1
>
> lglob: pl\utils.lua:19: redefining global unpack (if 5.2)
> lglob: pl\utils.lua:20: redefining global loadstring (if 5.2, make it an
> alias for load)
> lglob: pl\utils.lua:243: redefining global setfenv (if 5.2)
> lglob: pl\utils.lua:258: redefining global getfenv (if 5.2)
> lglob: pl\utils.lua:287: redefining global table.pack (if 5.1)
> lglob: pl\utils.lua:292: redefining global package.searchpath (if 5.1)
> The glaring issue is that it defines set/getfenv for 5.2, and I think that
> this should become utils.getfenv, just as utils.execute is a more-portable
> form of os.execute.
> Not sure about table.pack and package.searchpath. Useful for
> compatibility, but I wonder if doing it always is being sneaky.
> (PL should move to a more capability-driven model here anyway, since
> LuaJIT defines package.searchpath for us anyway)
> But what's the general feeling about this (sneaky) way to support portable
> code?
> steve d.
Imo drop it. Add something like
require("pl.compat51")
and/or
require("pl.compat52")
they can then export the globals, best they only export globals if they detect their own usefulness. Eg. doing require("pl.compat51") on a 5.1 install shouldn't change anything
Thijs
PS. A good utility function to detect the runtime would be nice (5.1, 5.2, LuaJit 1/2, any others?), to circumvent the issue mentioned by Dirk (checking on getfenv)