|
"Andrew Starks" <andrew.starks@trms.com> wrote:
> <james.c.graves.jr@gmail.com> wrote:
>
> > The goal is to isolate all the modules from each other and eliminate
> > unintentional pollution of the global environment. Every module has
> > access to only just what it needs, no more and no less.
>
> That goal makes sense.
>
> Could you please provide an example where this isn't already the case,
> and make it one that does not involve the module writer returning
> "_ENV" as the return value of their module?
>
> If this is all about 5.2, then I don't see how there is a need to do
> anything weird at all. If the module writer wants an isolated
> environment, then they set _ENV to the local environment that you want
> and if you want a common one, make a module that returns a table of
> your desired environment and set the one that you are working on to
> its return value.
>
> This does not expose anything to any other module outside the one you
> are targeting, provided that you do not return _ENV as the value.
> Returning the normal table would not bring along anything in that
> module's environment.
>
> I think I'm missing something because I keep typing that and I keep
> not seeing why there needs to be any additional metatable magic.
One of my goals with this design for an import statement is to eliminate a lot of the boilerplate code you normally need to achieve what we're talking about.
I'd like to just have an import statement at the top of the module, and a return at the end. The exported functions could just be declared without the 'local' keyword, and the non-exported functions with 'local'. There would not be a need to build a table to return the exported functions.
It could be more concise than how it is normally done now.
James