Re: Require

[Edgar Toernig <froese@...>]

Diego Nehab wrote:
>
> 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

Fine.

>     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

Fine.

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

Hmm... I don't like the setfenv idea.  Let the library decide where
it puts its stuff.  "Clean" libraries won't do nasty things but still
be able to replace/add globals.  IMHO, a recommendation on how "clean"
libraries should be implemented would suffice.  Don't force developers
to a specific model.  (Btw, I'm still hoping that setfenv gets nuked
in 5.1 *g*)

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

Agree.

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

Fine.  Let require just cache the first result (possibly nil) of the
init function.  Nothing more.  Whether a library actually returns a
namespace table or not should be irrelevant to require.  It's the
policy of the library.

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

Right, that's a difficult part.

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

Hmm... why?  require is just a front-end.  Sure, one has to decide at one
point which actual loader is invoked but shouldn't it be at a lower level?

An extendable loader system that is able to determine both location and
type of the data and invoked via loadfile() would be marvelous.

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

To have the possibility to wrap any library with a Lua script is IMHO
crucial.  But force it?  No!  Just think about statically linked
libraries...

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

The less policy you put into require the easier it is for the library
developer to take care of that *g*

> These are my $2... :o)

And my 2 Euros ;-)

Ciao, ET.