[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: External modules was Re: Ideas for implementing commercial support for Lua
- From: "Pyrogon Public" <public@...>
- Date: Fri, 15 Nov 2002 12:13:45 -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.
I disagree. Both implicit and explicit loading of shared libraries are
fairly common across a wide range of platforms. Obviously, they can't
be implemented on ALL systems, but even DOS had this facility via
overlays and even loading Windows DLLs under DOS4GW.
Under Win32, you have the LoadLibrary()/GetProcAddress() calls; under
Unix there are dlopen()/dlsym()/dlclose(); under MacOS you could use the
Code Fragment Manager to dynamically load code resources; under OS X
there are NSBundles; under Carbon for MacOS/OS X there are CFBundles;
there are shared libraries; and many other operating systems support the
notion of dynamically loading code.
So as a concept, the ability to "load a piece of code and call it from
Lua" is generally applicable, but because this isn't ALWAYS the case, I
would think it should stay out of the core or at least be conditionally