[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Private modules, was Calling module from a C function
- From: Thomas Lauer <thomas.lauer@...>
- Date: Thu, 26 Apr 2007 10:03:53 +0100
Tomas Guisasola Gorham <email@example.com> wrote:
> On Wed, 25 Apr 2007, Thomas Lauer wrote:
> > However, an official function in module package to *selectively* import
> > stuff from other modules would be a welcome addition to the module
> > system, IMHO. I know that's easy to write, but as usual everybody will
> > have his or her own version and it all won't play nicely together.
> Have you wrote your own version? I think a copy function
> is easy to write, but I'm not certain on how to handle function
> dependencies when importing a function f from module A to module B.
> What to do if f uses a global g and B already has a member g?
Hm... this should only be of concern if the modules in question use
'seeall'. Don't use it and this sort of problem can't happen: all
accesses to functions are then "hard-wired" in their respective modules
and as such won't go through an __index metacall. (Of course, it is
still perfectly possible to willy-nilly change any and all addresses in
the module tables, but this has to be done explicitly.)
But perhaps I have misunderstood your question.
> But `require' only passes its first argument to the script :-(
Yeah, that's one of my pet peeves as well. It would be a really great
addition if ll_require() would push further arguments before it calls
the loaded module. ll_module() could then simply access these as further
parameters. This should even work with C libraries.
Alas, doing this would break most existing module code.