Re: Local as table

[James Graves <james.c.graves.jr@...>]

steve donovan <steve.j.donovan@gmail.com> wrote:
> On Thu, Feb 21, 2013 at 8:50 PM, James Graves
> <james.c.graves.jr@gmail.com> wrote:
>> import { _ENV,
>>     baz = "foo.bar",
>>     math_iz_awezome = "math",
>>     "os",
>> }
>>
>> Hmmmm.... maybe I should write that up.
>
> That is very Go-ish indeed. The _ENV could be implicit (import could
> look it up as upvalue of calling function, or fall back to getfenv).
>
> A cool feature is that 'require' is implicit here.
>
> But now, how about the 'leaky module' problem, which is why
> module(...,package.seeall) got such a bad rap?  Your new module will
> be displaying its underwear, e.g. we could access os, which might very
> well be a no-no in another context.
>
> One solution would be to use a shadow table - you put everything you
> want into _ENV, but keep an _actual_ module table; _ENV will have a
> __newindex which will write any new functions into the module table.
> One just has to remember to return that module, not _ENV itself.
>
> (Very much on my mind because I'm revisiting Penlight's strict mode
> and generalizing it for modules; Andrew has suggested a most
> entertaining import mechanism but I'm worried about the underwear
> problem)

Yes, I agree with all that.

Just so I understand what needs to be done...

Upon entry into the import function, we need to grab the _ENV using
debug.getupvalue().  Can I use that table as-is, or do I need to make
a new one which uses the old _ENV (or possibly _G) for __index?

After that, we'll be loading all the imported functions (possibly with
renaming the end result) using load() (or possibly require() not sure yet),
so that we can pass in our desired environment where everything is
stored.

At this point we can set the __newindex function for the current
environment as you mention above.  We will also stick a reference for
this in the current environment, called _MODULE or something.

Then after the import() returns, the module can declare functions without
the 'local' keyword, and those will go into the _MODULE table.

And at the end of the file, we return _MODULE.

Does that sound plausible?  A bigger question is: Does that sound
desirable?

James