Re: Refactoring progress report

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-05-14 06:28:46

Vladimir Prus <ghost_at_[hidden]> writes:

> 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
>> defined).
>
> Does this cause lot of problems? Does one need to import unacceptable amount 
> of rules? Or this cause performance problems?

I don't know yet. I'm not profiling anything.

>> 2. That also means that modules imported into base classes are
>> visible in derived classes.
>
> What's the problem with it? 

It's more-liberal than we might like. The desire was to see the
import dependencies in any piece of code by looking at its file.

>> 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?

Yes, at least, all the rules that are used by that instance. The
global module is hardly getting used at all, except for accessing the
methods of class instances:

$(some-instance).some-method

should work everywhere.

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

Hope I've clarified.

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

Yes.

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