From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-14 01:12:47
David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> >> o Explicit Importing
> >> Currently "import foo" in a module doesn't guarantee that the module
> >> is dependent upon foo and the absence of "import foo" doesn't
> >> guarantee that the module is NOT dependent on foo. The latter is
> >> because "import foo" in another module makes foo rules available
> >> globally.
> >> ...
> >> The solution is to modify "modules.import" to make foo rules
> >> available only to the module that is importing them.
> > +1
> As I'm implementing this, I'm discovering it has downsides as well:
> 1. Since class instances are modules, each class instance that wants
> to use a module must have imported it in one of its methods (class
> instances can't see anything from the module in which they were
Does this cause lot of problems? Does one need to import unacceptable amount
of rules? Or this cause performance problems?
> 2. That also means that modules imported into base classes are
> visible in derived classes.
What's the problem with it?
> 3. There's a memory and speed penalty associated with this.
Does it arise from the fact that all the rules are entered into symbol tables
of all the class instance modules?
> We could get around 1 and 3 by allowing module nesting, so that each
> class instance would be able to see the rules defined in its
> enclosing module... but this wouldn't get around #2, which would
> require a much more-sophisticated search mechanism that looks through
> base classes first.
I still don't understand #2....
> ...or we could just embed a Python interpreter in our system and be
> done with it (I'm only half-joking).
One day... probably. But I have no idea if it's possible now -- it will take
unpredictable amount of time.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk