 |
lua-l archive |
|
|
||
|
To use a specific example, there is a MIME module in LuaSocket that needs
some C support, but also has Lua code. Thus, there is a mime.dll and a
mime.lua. The user calls
mime = require"mime"
and is happy. In mime.lua, however, I have to load mime.dll. It is good to
be able to do this without worrying about using different names for the C
and the Lua part of the library. I just do
local mime = requirelib("mime")
... define Lua functionality
return mime
The implementor *knows* which is which. Why eliminate this freedom?
In LuaCheia we have the cheia.load('mymod') a nd the cheia.loadmodule('mymod') The first does only load the Lua stub 'mymod.lua' which the in turn (may) use cheai.loadmodule('mymod') to load the dll/so, cheia.loadmodule also figures out the proper filename for the binary module and then uses loadlib() to actually load it... (which releys on the fact that we have a entry-point naming convenmtion...)
But ofcourse the Lua/C developer can use any way to actually load the binary. Glua-X modules e.g. need a different approach. By using cheia.load() to load a Lua stub this is all in the hands of the developer...
I'm very looking forward to what this discussion will result in! my 0.02EUR -Martin