Re: Private modules, was Calling module from a C function

[Thomas Lauer <thomas.lauer@...>]

"Jerome Vuarand" <jerome.vuarand@ubisoft.com> wrote:
> An example may be clearer. Suppose that you have a loader that get Lua
> rocks from the net:
> 
> -- Install the loader
> require("rocks.loaders.http")
> 
> -- Get some modules from the official rocks website (fictionnal url)
> require("lxp", "http://rocks.lua.org/";)
> require("pdf", "http://rocks.lua.org/";)
> 
> -- Get some modules from your corporate intranet quality assurance site
> require("syslog", "http://qa/";)
> 
> And from here you can use modules lxp, pdf, and syslog as normal
> modules. There are other solutions to the problem, I could for example
> embed the url in the module name like require("org.lua.rocks.lxp"), or
> as methods of the loader module, but that can be done to modify normal
> modules too. My point is that extra parameters to require may be used to
> configure how module are loaded rather than how modules will work.

Such an extension to the current model could perhaps be implemented with
a table as require()'s parameter. Most, if not all, fields would be
predefined, so as to standardise usage. Ideas would include:

require("syslog")       -- would still work, with same defaults as now
-- or alternatively
syslog.name="syslog"
syslog.loadmethod="lua" -- could also support a pointer to a function
syslog.location="http://localsite/";
syslog.param={"whatever"}  -- could be used for module initialisation
require(syslog)

There are certainly other things one could think of.

Such an approach would basically parameterise the "monolithic"
require(). And if the loaded module gets this table as well, it could
get information about how and where it was loaded, what parameters were
used etc.

-- 
cheers  thomasl

web : http://thomaslauer.com/start