Re: package proposal

[Mark Hamburg <mhamburg@...>]

on 1/6/05 10:56 AM, Diego Nehab at diego@tecgraf.puc-rio.br wrote:

>> Does one really want the exported namespace for a module to inherit the
>> globals?
> 
> I believe the original idea  was to have globals defined after the call
> to module("foo") fall in the namespace for "foo" instead of in _G. This
> is something I really like and I would fight to keep. :)

I agree.

> As colateral damage, once module("foo") replaces the environment of the
> caller, no globals are visible anymore. To remedy this, the __index
> metamethod of the namespace itself was made to point to the original _G.

Useful, but if you look at the code in my message you will see that while _G
is visible in the function environment for the module it isn't visible in
the exported namespace. I also kept values like _PACK out of the exported
namespace.

> Since you can capture all needed globals before calling module("foo"),
> perhaps this fix should be removed altogether. I prefer the complete
> removal to a more complex solution (Lua philosophy...).
> 
> We can also leave it as it is because one can remove the __index
> metamethod from the namespace after calling module("foo").

That would seem to have problems with functions that accessed globals in
their implementation -- e.g., calling table.insert -- since the function
might not be called until after we had removed the __index metamethod.

Now, of course, since one doesn't reference table.insert but instead writes:

    local table = require "table"

That isn't an issue. ;-) A change like that, however, would probably confuse
a lot of people since it makes module code different from, for example, PiL
code.

Mark