Re: Refactoring progress report

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-05-13 16:08:36

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
defined).

2. That also means that modules imported into base classes are
visible in derived classes.

3. There's a memory and speed penalty associated with this.

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.

...or we could just embed a Python interpreter in our system and be
done with it (I'm only half-joking).

Thoughts?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com