Re: modules, require, magic

[Hisham <hisham.hm@...>]

On Thu, Oct 20, 2011 at 3:03 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> > Moreover,
>> > a modified 'load' function forces everyone to live with its magic.
>>
>> Not necessarily; Fabio's original loader did this but loader5
>> restricted the magic to the users of module().
>
> Maybe I am missing something, but I got the impression that, with
> loader5 (as posted to the list), I get an empty environment if I do not
> call 'module'.

Indeed; and at a first glance I don't seem to be able to fix this
without resorting to the debug library. In any case, at this point I
assume that "_ENV = module('name')" would be the preferred direction
to go for a possible Lua 5.2 version of module().

>  local function loader(name, modpath)
>    local mod, env = {}, {}
>   env.module = function (name)  ...   -- not called
>   ...
>   local ret = assert(load(source, modpath, 'bt', env))(name)
>   ...
>  end
>
> Moreover, it seems that loader5 has some other drawbacks. (It needs to
> read the whole module as a string; all accesses to globals go all the
> time through function calls.)

With the module() + package.seebase variation suggested at [1] I think
the only remaining drawback would be that all accesses to globals go
all the time through function calls when using package.seebase.

Myself, I could live with that (resorting to the ugly "local
print=print" idiom if performance was really needed); I'd rather take
this hit than the other issues of package.seeall (in which globals
already go through a metamethod anyway, no?), or having to localize
every needed global from the base library.

Having said that, if the standard library remained the same as the one
in Lua 5.1, I'd probably keep using package.seeall instead of rolling
my own package.seebase, for the sake of sticking to standard idioms.

[1] http://article.gmane.org/gmane.comp.lang.lua.general/84444

-- Hisham
http://hisham.hm/ - http://luarocks.org/