Re: module & 5.2

[Jerome Vuarand <jerome.vuarand@...>]

2012/4/1 Petite Abeille <petite.abeille@gmail.com>:
> In 5.1, one could do the following out-of-the-box, courtesy of module:
>
> (1) define a self-contained, self-registered  module with a one-liner
>
> (2) define multiple modules per source file
>
> (3) package multiple lua source files into one file, courtesy of cat, without further ado
>
> (4) package multiple lua source files into one compiled file, courtesy of luac -o, without further ado
>
>
> Not so much with 5.2 as:
>
> (a) module is deprecated
> (b) even though module is still defined and enabled by default, its implementation is not backward compatible in terms of (2), (3) and (4) which renders it rather pointless and dangerous

Your points (2), (3) and (4) were only possible in some circumstances.
For example if you used "module" without package.seeall, further calls
to "module" (be it in the same file or in a concatenated file) would
be considered an access to an undefined global variable. Also it would
have been beneficial to use the do/end block boilerplate to avoid
local namespace pollution (ie. if first module define local foo, and
second module access global foo, concatenation is broken).

So all in all you already had to take extra care when having several
modules in the same chunk. In 5.2 the global variable mechanism
changed a lot, the module system was adapted, so the care you have to
take is different. You can argue that you have more stuff to do now,
but that's only if you previously used the much despised
package.seeall.

I still have to do the switch, but I think I'm gonna try the portable
approach for 5.2 evolution, ie. write 5.1 and 5.2 compatible modules,
that simply return a table, rather than using the module function. I'm
one of the people that has always been bothered by the global
namespace polution that module incurs (it's nice to keep small scripts
short, but with large projects it can lead to troubles).