lua-users home
lua-l archive

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



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.