[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Packaging and importing
- From: Wim Couwenberg <w.couwenberg@...>
- Date: Wed, 17 Aug 2005 10:13:33 +0200
> ... 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
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