Re: More about packaging (hopefully not too long)

[Jamie Webb <j@...>]

On Tuesday 08 June 2004 06:11, Diego Nehab wrote:
> -- Globals polution ----
>
> I agree with RLake and I don't like the polution, but this is not the end
> of the world. An user could override whatever is the library's behaviour. I
> think the library should return the namespace anyways, so that "require"
> works well.

Messing about with environments to 'trick' a library seems like a hack, not a 
solution. Doing it the other way round is much cleaner.

> Whatever we do, I prefer that each library creates its own table.
> Having the library receive a table to fill doesn't seem to be so
> advantageous.

I think that each library should be given a table to fill. The loader should 
create an empty one by default. There could be a convenience wrapper that 
makes that table a global, i.e. one can write any of.

-- The import function creates a new global table named after the module
import "socket"

-- The module function creates a new table by default
local socket = module "socket"

-- But you can also explicitly specify a table to use
local socket = module("socket", {})

Advantages of returning a table rather than making it global are that it makes 
life easier for people who want to rename the namespaces or shave off a few 
cycles, and it is far preferable that modules load their dependencies only 
locally, so that should be easy to do. It may also be essential given a 
hierarchical naming system. Actually, I've just convinced myself that the 
import function should not exist at all.

Advantages of passing a table to the library (aside from the one Rici gives) 
are that it is added flexibility at no real cost. Specifically, it makes it 
easy to combine namespaces of several related modules (e.g. if they are all 
loaded by the same stub, and the stub writer knows that they do not clash) or 
to load functions straight into the global table (e.g. to provide a tailored 
environment for end users).

> -- A Lua loader for every dynamic library ----

I'll comment on Rici's post here. It seems like an unnecessary complication to 
require that Lua code be embedded in a library in order to create combined 
libraries. In particular, it means recompiling the library every time the Lua 
code changes. The Lua stub approach is also handy to work around libraries 
that do not (yet) follow whatever conventions come out of this discussion, 
and it avoids searching two separate paths.

Mike Pall suggested that the stub could be a symlink. I don't think a symlink 
to the library is feasible, but a symlink to a generic stub which loads the 
library of the same name seems entirely reasonable (for Unix at least).

-- Jamie Webb