Re: Require

[Diego Nehab <diego@...>]

Hi,

> > 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*)

We still need a standard so that require() obtains the namespace to be
cached and return. I like the convention of returning whatever the chunk
returns.

However, I believe the most natural way of telling Lua which names
should be exported is the use of local/global names, and the best way to
do this is to have a function which libraries that choose to do so can call to
set thigns up. Roberto was thinking about a package(...) function for
this purpose (this is where the setfenv magic would happen).

In such a context, even libraries that choose to call package() can
still replace/add globals (_G.print = nil).

Libraries that don't do it could still return just the namespace they
created by hand.

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

Agree.

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

This is for extra freedom. LuaSocket, for instance, has a C part and a
Lua part. The Lua part, which is loaded by require(), wants to load
the C part. The C part might be a shared library lying somewhere, but it
might be linked statically. To ensure it will always work, I need
someone else to map names to C entrypoints, just like require() maps names
to Lua chunks.

It shouldn't be up to the library developer to come up with the mapping.
It should be up to the guy that is creating the instalation. This new
function would be part of the instalation, not part of LuaSocket.

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

*If* a C function and a Lua chunk could be treated exactly the same way,
I would agree.

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

What is the big deal? Just stick the loaded chunk somewhere the mapping
function can find. It doesn't matter if it's a Lua file in the filesystem,
a statically linked LOH or Lua source inside a resource. What matters is
that it *can* be any of these without changes to the library code.

It's up to the mapping function to find the loaders, and it's up to
whoever is creating a distribution to come up with a mapping function
and decide if it's going to be a LOH, a lua file etc.

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

And harder for someone who is putting 25 different libraries into a
distribution to figure out how to do it.

[]s,
Diego.