[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Re[2]: import and LuaBinaryModules
- From: "Martin Spernau" <martin@...>
- Date: Sat, 1 Mar 2003 00:03:42 +0100
From: "Doug Currie" <e@flavors.com>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Cc: <lua-l@tecgraf.puc-rio.br>
Sent: Friday, February 28, 2003 11:40 PM
Subject: Re[2]: import and LuaBinaryModules
> I just saw the recent posts on LuaCheia about "setglobals() and
> C-Functions" -- the Import solution is clearly superior to allowing C
> modules to write the global namespace.
> http://www.lua.org/notes/ltn011.html
>
> Import provides a table to the module where the module puts its
> bindings. So, the users can put the bindings in whatever "packages"
> they want, including temporary/local ones.
There was one argument about allowing arbitary names for modules, the need
for a well-defined name for certain functions (ather code relying on a
certain function being availeable under aknown name)
So we agreed to let the module set it's 'official' namespace and the user to
'alias' it. That way the binding will be where other code will expect it,
and the user can still use any name he desires...
Modules made with the Glua-X binding package hgave one great aspect: one can
specify the table a module will be loaded into when calling it.
I'm not sure if other loading mechanisms can do this.
(loadmodule relies on the modules own open_xy(luaStae *L) function, which
has the namespace hardcoded)
Here we think it would be ok to lets the module have it's way, and also maby
alias it to some 'proper' place like lib.xyz.foo()
-Martin