[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: package system modification (module loaders)
- From: Diego Nehab <diego@...>
- Date: Tue, 11 Jan 2005 20:23:21 -0500 (EST)
If you use the vanilla way of installing Lua packages, which is with Lua
modules and shared libraries in the filesystem, you don't need to change
anything. In fact, you don't even need to understand what is going on.
Things work automatically. The reason for that is that we believe the
Lua interpreter should "just work" with any library.
Naturally, Lua is used in embedded scenarios that we could never forsee.
Each specific user will probably have specific needs. A feature that is
important to you might not be to someone else. Conversely, a feature
that is useless to you might be fundamental to others. Rather than
trying to provide explicit support for every scenario, we instead
believe we provided mechanisms that are powerful enough that you can
taylor a interpreter to load libraries in a wide range of situations.
This is one of the situations we *have* forseen.
The package proposal states that a loader function will be searched for
in the package.preload table. This table exists to ensure it is
possible to bypass the filesystem search for the module. It's main use
is to enable static linking of modules, but it was designed with other
uses in mind (Lua modules loaded from Windows resources, from LAR files,
from Zip files, you name it).
Setting the __index metamethod of the package.preload table is a
perfectly fine way of overriding the standard search logic. It is just
as valid as filling that table at startup, with statically linked