[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re[4]: import and LuaBinaryModules
- From: Doug Currie <e@...>
- Date: Tue, 4 Mar 2003 22:29:17 -0500
Tuesday, March 4, 2003, 8:31:14 PM, Thatcher Ulrich wrote:
> In a nutshell, the objection I have to these gymnastics is that they
> don't solve the underlying problem, which is in order to avoid name
> clashes, modules need globally unique names. When you say:
> import "a"
> The "a" needs to uniquely specify the desired module. If someone else
> in the world implements a different module named "a", you still have a
> name clash, regardless of whether you can put the results of import()
> in an arbitrary table.
I disagree, at least at the language level.
In your example, "a" is just a (part of a) file name. It gets turned
in to "luaa.dll" by LuaBinaryModules, for example. A name clash here
can be fixed easily by renaming one of the files, perhaps to
"luaa-old.dll" and "luaa.dll" or putting them into different paths in
the file system.
Both of these modules, presently, have a name wired into their code.
Maybe this name is also "a" maybe not. So using the present
LuaBinaryModules mechanism, they'd clash when loaded.
Using the technique in http://www.lua.org/notes/ltn011.html I can load
both, e.g.,
local anew = import "a"
local aold = import "aold"
In fact, as above, I don't need to polute the global namespace at all!
That's one reason why I am recommending the ltn011.html mechanism for
binary modules. The other reason is so binary modules and lua modules
have the same behavior.
e