Re: [ANN] Lua 5.2.0 (work4) now available

[Matthew Wild <mwild1@...>]

On 6 August 2010 21:31, Petite Abeille <petite.abeille@gmail.com> wrote:
>
> On Aug 6, 2010, at 10:25 PM, Jonathan Castello wrote:
>
>>> Hmmm... perhaps I'm missing something very obvious, but how does one name a module in such a setup?
>>
>> I think it was mentioned earlier that the caller would decide where
>> the module would be put and under what name, i.e.:
>
> Hmmm... why should the caller need to know such details? The caller only need to know a module name, not the details of it physical representation (e.g. file or not).
>
>

I'm really not sure what you're saying. Perhaps you're misunderstanding.

In 5.1, module() allows a module to inject a table with a name of its
choosing into the main global environment. This means that not only
does the caller need to know what the name of the module *file* is,
but also what the module name ends up being (it may seem ridiculous
that a module would have one name on disk and another name when
loaded, but this is exactly what many 5.1 modules already do). Also
note that this global-writing is incompatible with most sandboxes.

Now, in 5.2 a module returns itself... the caller explicitly assigns
it a name, which may or may not be global, but either way it then
knows where to find the module when it needs it. When you say "why
should the caller need to know such details?" I don't know what you
are referring to - the caller now *only* needs to know the name of the
module on disk (or wherever it is being loaded from). An improvement
for sure.

Now it should be noted that I'm not sure I'm in favour of removing
module(), just against its global-writing (and possibly package.loaded
writing) behaviour. My complaint about the local _ENV = {} is that it
just looks a little too cryptic compared to 5.1's module("mymodule").
However generally this is all a (large) step in the right direction.

Matthew