[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: package proposal
- From: Mark Hamburg <mhamburg@...>
- Date: Thu, 06 Jan 2005 11:52:41 -0800
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