Re: More about packaging (fwd)

[RLake@...]

A couple of quick notes, since I think
my previous post was too long :)

1) Inserting modules into the global
namespace is just bad practice. However, for lazy coders there is no problem
setting a metamethod on the global table which will trigger the require
-- the only issue is figuring out which globals might be module names.
Alternatively, you could define:

function import(name)  _G[name]
= require(name) end

which will work fine if the project
doesn't change environment tables, and will satisfy the lazy programmer
market, I hope.

2) In my opinion, the standard name
for a library module ought to define a published interface description,
not a particular implementation of the interface. Having a system which
allows me to have multiple implementations (or multiple versions of a single
implementation) simultaneously makes regression testing much simpler. If
a module clobbered the globals table on instantiation, this is much harder
to do.

There is another pending discussion
on environment tables, but I won't get into that right now.

3) The sample code I provided allows
me to use the same .c code for a static or a dynamic library with no modifications
whatsoever, but it does have the weakness that the name of the module must
correspond to the name of the entry point. After trying a few alternatives,
I decided I could live with this. I use a script to build a makefile for
the lib subdirectory; the script creates a little stub which registers
(but does not load) the static libraries it encounters there. I personally
prefer to have my lua's built with static libraries for production use,
so it is convenient for me to be able to just move the source file into
the lua build directory and do a make.

R.