lua-users home
lua-l archive

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

Javier Guerra Giraldez wrote:
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).

Only people who have been drinking their own kool-aid for far too long could consider the practices that will replace "module" something simple and clean. The method advised is both probably unique to a particular programmer and wide open to strange customizations at every level. Where "module" expresses a well established idea in this business, defining a function and _ENV in one of a couple of dozen possible different ways means that the goal of "module", modularity, will be worked out in so many different ways, that modularity will only work within the code of one individual. A module is conceptually not a library, even though one can use the form of library to create a module. Yes, you will have eliminated one keyword from the language, but in the process you will create tortured code that will far exceed the that found in implementing module. And, if you want to encourage modular coding, there need to be clear and accepted practices for building modules that can be easily loaded, run, and unloaded, and possbily serially re-used, fully re-entrant, co-routines, and/or resident and self-modifying or persistent. I am sure I missed a combination or two, but that is a fair explication of the range of needs that can be found for modules out there. Throwing environments around like rice at a wedding will assuredly create situations that an octopus couldn't untangle...speaking of scope problems. Yes, that is powerful and compact, but simple and clean, not on this planet.