[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Local as table
- From: steve donovan <steve.j.donovan@...>
- Date: Fri, 22 Feb 2013 09:49:53 +0200
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)
steve d.