Re: More about packaging (hopefully not too long)

[Diego Nehab <diego@...>]

Hi,

Sorry for the delay, but there was no internet in the plane... :o)
This became an interesting discussion, and I will try to catch up by
giving my 2c on some of the topics that showed up.

-- 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.

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. Besides, libraries written in Lua would require deeper
modifications.

-- Naming convention ----

This is a hard one. The name of my library is LuaSocket, but I used to call
the namespace "socket". Now, the namespace is gone and the user can call it
anything he likes, but there is still the problem of the library name.
Each implementor has to choose his own. I prefer to run

    socket = require"socket"

instead of

    socket = require"luasocket"

so there is a socket.lua somewhere that loads the dynamic library.  What to
call the dynamic part is another problem. I am not bold enough to call it
just socket.dll, so there is a luasocket.dll somewhere (should I be bolder?
this library will be in the Lua tree anyways...)

I am afraid we will exaust this "global namespace of library names" pretty
soon. Other languages (and some Lua distributions) have a hierarchy scheme,
right? This would be another long discussion... My hint here is that the
require function might have to become aware of *some* kind of hierarchical
naming convention.

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

I agree it is a good idea in the user's viewpoint: it shouldn't matter
if the library is written in Lua or in C. However, let's not mistake a
user with the poor soul that is implementing the library. It would be good
if the developer could make the distinction.

To use a specific example, there is a MIME module in LuaSocket that needs
some C support, but also has Lua code. Thus, there is a mime.dll and a
mime.lua. The user calls

    mime = require"mime"

and is happy. In mime.lua, however, I have to load mime.dll. It is good to
be able to do this without worrying about using different names for the C
and the Lua part of the library. I just do

    local mime = requirelib("mime")
    ... define Lua functionality
    return mime

The implementor *knows* which is which. Why eliminate this freedom?
I disagree with Mike Pall on this.

-- Static and dynamic running the same code ----

All we need is for require and requirelib (if we stick to it) to work
regardless of the library being static or dynamic. This can be done, sort
of, if each library sets the entries in _LOADED and _LOADEDLIB by hand.
It still works in the dynamic case, and prevents require/requirelib from
trying to load something in the static case.

The only problem is garbage collection. For the dynamic case, we want the
tables (_LOADED and _LOADEDLIB) to be weak. For the static case,
they *can't* be. Any solutions here?

-- Unloading of libraries ----

I think that if we do automatic unloading, it has to be safe. If it is
unsafe, it certainly can't be automatic. I like Edgar's idea, as long as
static and dynamic can be made to work without too much change to source
code. So far, the solution seemed a bit too involved than I would like.

If we go ahead, I would just like to remind that the library itself has
to know it is being unloaded, and we should provide for it.

[]s,
Diego.