lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Fri, Aug 6, 2010 at 3:21 PM, Petite Abeille <> wrote:
> On Aug 2, 2010, at 2:36 PM, Roberto Ierusalimschy wrote:
>> Now the "usual practice" seems so simple that it does not
>> deserve a helper function. Just write this:
>>   _ENV = {}
>>   ...
>>   return _ENV
> Hmmm... perhaps I'm missing something very obvious, but how does one name a module in such a setup?
> Or, conversely, a module defined across multi files [2][3].
> Or one concatenated file containing multiple modules [4].
> Either way, removing the module function will lead to a net loss of functionality.

my 2 centavos (S/.):

the require() function hasn't changed (AFAIK), so there's no
difference for users of libraries.  that also means that what a
library must provide to its users hasn't changed either.   if your
libraries did advanced package managing, you can still do the same; so
i don't think it's a 'real' loss of functionality, just (maybe) a loss
of convenience

just as before, the require() function has some flexibility on the
requirements, but the environment management changes in 5.2 make it
much easier to create module tables without globalspace polluting.  so
much easier that the recommended procedure becomes just two lines of
code.  evidently, for that generic case, there's no need of a built in
function.  removing it _is_ a step forward in minimality  (core Lua is
a minimalistic language, remember)

for 'advanced' packages, you can always replicate what module() did.
it's not difficult; for example, a multi-module file previously done

module( 'URLPath' )
module( 'URLParameter' )
module( 'URL' )


local _G=_G
local function submodule(s)
  _G.packages[s] = {}
  return _G.packages[s]

_ENV=submodule( 'URLParameter' )
_ENV=submodule( 'URL' )
return _ENV

and something similar for multi-file modules.

i think the point is about making the 'simple and clean' case even
simpler and cleaner.  module() too many different things, making the
simple case not so clean.

personally, i do like this proposal; i hope it will encourage library
writers to stay in the simple case, and verging away from it only when
it's honestly convenient (to the library user).