Re: Packaging and importing

[Wim Couwenberg <w.couwenberg@...>]

> ... I don't know exactly what is your scenario, but I now tend
> to avoid this double-dependency. Having C code depend on Lua code tends
> to complicate the setup, ...

The scenario is very much like that proposed in the reply by Shannon
Stewman, but with the roles of C and Lua reversed of course.  Not
complicated at all I think.

> Why worry about someone being able to load an internal module? 
> If someone does that, it should be their problem, shouldn't it? 

It should!  :-)

> This is somewhat assymetric. One of the ideas of the packaging system, I
> think, is that you can place the same function in the package.preload
> table and everything should work fine. In that case, you would be in bad
> shape.

OK.  I guess that if it's in the preload table, the environment is
under tighter control anyway, so the problem more or less goes away.
But I get your symmetry point.

>> Don't you agree that it would be much nicer if we only need to use
>> "module" and not rely on return values?

> I am not sure. The current scheme makes it work in 99% of the cases with
> no setup. With one extra line for the other 1% you can get it to work.
> Is this too bad?

Maybe not.  With a slightly updated module function, we don't even
need that extra line though.  But I'll stop yacking now...   :-)

>> 1)  "module" binds to the "require"-ed name, not to the module name.

> And how is "module" supposed to know what was the required name? Maybe
> some magic environment trick...

No magic at all.  I implemented it (in Lua of course!) by letting
require and module share the required name through an upvalue.  In a C
implementation you have to share it in some other way.

>> 3)  Drop the support for package return values, they're just confusing

> I don't like this idea.

And you're right!  Sorry.  Using both a module call and a return value
in a single package still is a bit confusing though... (sort of mixing
package styles)?

--
Wim