[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: External modules was Re: Ideas for implementing commercial support for Lua
- From: "Brownsword, Andrew" <brownsword@...>
- Date: Fri, 15 Nov 2002 11:43:42 -0800
I object to the "including a DLL loader" statement. It carries a lot of meaning that you perhaps did not intend -- most platforms don't have "DLLs", and "loading" would not be appropriate either. If you mean a system by which you can bind additional functionality into Lua at runtime without changing the Lua source code, then that could be quite useful (assuming it doesn't cause a performance hit). If you mean a Win32 DLL load implementation then that has no place in Lua, except perhaps as a sample implementation of how to use the runtime binding facility.
One thing we are looking at, in particular, is how to add a couple of data types to Lua without having the overhead associated with metatables and Lua/C calls. The operations on these types are very quick, on the order to 10-20 times faster than just making the call to C, and it would be much faster if these could be intrinsic operations in the VM.
-----Original Message-----
From: Thatcher Ulrich [mailto:tu@tulrich.com]
Sent: Friday, November 15, 2002 11:15 AM
To: Multiple recipients of list
Subject: Re: External modules was Re: Ideas for implementing commercial
support for Lua
On Nov 15, 2002 at 07:26 +0100, Bj?rn De Meyer wrote:
> Philippe Lhoste wrote:
> >
> > Yes, Lua must still be available as Ansi C source code and small binaries.
> > We should never have to strip down Lua to get small binary, but instead be
> > able to download various extensions, perhaps as a whole package if needed.
> > If someday we devise a standard way to extend Lua as scripting language,
> > using external modules, it would be a great improvement.
>
> This is the key feature that Lua should aquire. An advanced
> system by wich available C libraries can be easily integrated,
> without recompiling.
Actually, several such systems exist; the problem is there's no
officially-blessed standard. I think the most Lua-like approach to
this is Ignacio Casta.o's luselib (but I can never find the URL when I
look for it! ):
Anyway, we've gone over this before. My summary: some users
(especially embedded developers) thought that including a DLL loader
in the Lua distribution would be the thin edge of the wedge towards a
bloated distro, and objected; others (including me) thought it would
help extend Lua without bloating; the result was that Lua authors
added the LUA_USERCONFIG and lua_userinit hooks to lua.c in 5.0-alpha.
... edited for brevity ...