Re: modules, require, magic

[Fabio Mascarenhas <mascarenhas@...>]

On Wed, Oct 19, 2011 at 1:32 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> In terms of "fixing module()", I think Fabio's implementation is right
>> on the money:
>>
>> http://article.gmane.org/gmane.comp.lang.lua.general/84283
>
> What exaclty is it trying to fix?

1. anything provided to the module through its environment becomes
available to the module's clients (this is the
2. "module" exporting the module to the global environment by default

The first is the biggest wart of "module", IMHO, and the infamous
http://lua-users.org/wiki/LuaModuleFunctionCritiqued seems to agree.
The problem of a module seeing other modules that it did not require
is related to "2" in this implementation, but it can be solved
independently of "2" easily enough.

>
>> It shows that a sane implementation of module() can be done with
>> standard Lua mechanisms. Do any of the anti-module proponents see any
>> problems with that design? Would you hate module() as much as you do
>> now if it behaved like that instead of the way it behaves in Lua 5.1?
>
> Isn't it even more complex/magic than the current implementation?

The implementation is more complex, but the end result is that a
module exports its top-level definitions and only those, while still
having a richer environment. There is still a wart in that modules
become immutable in practice (although the module can still make
changes to its external interface by going through package.loaded),
but I believe most Lua code assumes that a module does not change once
its loaded, given that caching module definitions is a common idiom.

> If you really want 'module', wouldn't be simpler to use
>
> _ENV = module(...)
>
> with a simplified version of 'module'?

I assume you would also need to "return _ENV" in the end of the module
for this to work, this is unecessary boilerplate if we have the nice
"loadin" mechanism in the standard library. It does not solve problem
"1" above, either.

On the *why* of having a tighter policy for modules, I believe Hisham
has already made a great case for that.

> -- Roberto
>
>

--
Fabio Mascarenhas