Javier Guerra Giraldez wrote:
On Fri, Aug 6, 2010 at 3:21 PM, Petite Abeille <petite_abeille@mac.com> 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
like:
module( 'URLPath' )
...
module( 'URLParameter' )
...
module( 'URL' )
...
becomes:
local _G=_G
local function submodule(s)
_G.packages[s] = {}
return _G.packages[s]
end
_ENV=submodule('URLPath')
...
_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.
|
