Re: Require

[Diego Nehab <diego@...>]

Hi,

Here are the main ideas I have been trying to sell. I have thoughts on how
to sort out some of the arising problems, but the important thing is to make
sure the ideas are good.  The two main goals I advocate are the following:

    Client scripts should be as portable across distributions as possible
        local socket = require"socket" -- should work if LuaSocket is there

    Library code whould be independent of packaging
        Lua code can be on filesystem, in loh, in resource.
        C code can be statically linked or in shared library

I believe the best way to define which symbols get exported into the
namespace is the local/global paradigm, implemented with setfenv.

    For purists, it *is* possible to prevent the global environment from
    being visible inside the namespace, so I only see advantages.

I also believe it is worth it to add cycle awareness to the require()
function. It's just one line of code anyways.

I like the idea of hierarchical names, such as require("socket.http").
I don't care if the namespace is actually exported into a global
socket.http, as long as it is *also* returned by require().

The biggest challenge in the is how to map a name, such as
"socket.http", into a function (loaded Lua chunk or a C entrypoint)
to be called. There doesn't appear to be a way to make everyone happy.
I believe the best way to do it is to provide some standard that works
for mainstream OSs (those that have directories, at least) *and*
provide an easy way to override the mapping function, preserving the rest
of the functionality.

I think that it will be hard to get require() to deal well with both C and
Lua libraries (very hard to find a mapping function that does a good job).
I really believe we need a function that behaves somewhat like require(),
but targetted at loading C libraries. Still, the user should only care
about the require() function. It's the library developer that needs to care
about the other function.

I think every C library should have a Lua loader module. These loaders can
be really simple and efficient and add a lot to the flexibility of the
packaging system. Require() would only deal with those loaders. The loader
than has to find the C code to load, and here is where we need the
equivalent of require(), but for C code.

It is especially important to allow libraries that have both C and Lua
parts to share the same namespace during the export process.

The developer always knows what he is writing, so I think the attempt use
require() for everything doesn't help, but is instead harmful (can't have
same name for C part and Lua part, forcing artificial aliases).

These are my $2... :o)

[]s,
Diego.