Re: [jamboost] Re: Refactoring progress report

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

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.

- Volodya

>
> Thoughts?