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

[Petite Abeille <petite_abeille@...>]

On Aug 7, 2010, at 5:10 AM, Mark Hamburg wrote:

> -- Define a module with functions foo and baz:
> 
> local M = { }
> 
> return M
> 
> 
> This hardly seems particularly bizarre and it doesn't rely on tricks with environment to change global assignments into exported values.

Two things:

(1) The above setup implicitly assumes a one-to-one relationship between physical Lua files and module names. In other words, the name of the module is derived from the physical file name the code resides in. 

(2) The namespace accessible to the module is global, as opposed to a more self-containded, closed environment provided my the current module/setfenv (i.e. package.seeall vs. not).

These are show stoppers for me.

Addressing them could results in something along these lines:

-- (1) Explicit naming
local M = package.loaded[ 'MySnazzyModule' ] or {}

package.loaded[ 'MySnazzyModule' ] = M

-- Explicitly name a module, irrespectively of its physical representation. No need to return anything, nor assume a file structure.


-- (2) Closed namespace

local _ENV = package.loaded[ 'MySnazzyModule' ] or {}

package.loaded[ 'MySnazzyModule' ] = _ENV

-- Closed namespace. _ENV is now the only namespace the module can mess with.


This starts to resemble the module functionalities all over again, but in a rather cryptic way. 

To quote Matthew Wild on that same topic:

"My complaint about the local _ENV = {} is that it just looks a little too cryptic compared to 5.1's module("mymodule")."