Roman Yakovenko wrote:
> On 7/26/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I was just trying to trace through the code in declarations.scopdef and
>> I ran across a comment in declrations._init_.py about needing to use a
>> rather interesting set of dictionaries in scopdef_t to inject some types
>> for use when looking up matchers.
>>
>> There is a comment on line 223 saying this is to prevent recursive
>> imports, but it doesn't go into details about what imports cause this
>> issue. Could anyone shed some light on this?
>
>
> In order to improve performance scopedef_t class instance contains few
> dictionaries:
> _type2decls, _type2name2decls, _type2decls_nr, _type2name2decls_nr.
> ( nr = none recursive )
>
> Now, in order to build all those dict, it needs to know all
> declarations types. This inlcudes
> namespace_t and class_t. But scopedef_t is a base class for those
> classes.
> So, I added 2 new class variables:
> _impl_all_decl_types - this is a list of all declaration classes
> _impl_decl_types - this is a dict that maps between scopedef_t
> select method and
> declaration class.
>
> Did my explanation help?
>
The explaination helped. I am still a little confused though. How did
this problem manifest?
It would seem that if we have:
scope_def_t:
import namespace_t
namespace_t:
import scope_def_t
Then importing namespace_t should be fine from user code as long as
scope_def_t doesn't use namespace_t in the module/global scope.
Assuming you are interested in removing this hack, there may be some
ways around this cycle though, what I can think of right now is:
- import the derived types only in the course of executing the
optimization methods. This would delay the import until scope_def_t is
fully defined.
- Just move all the optimization code to a helper class that scope_def_t
uses if optimizations are enabled.
Personally I like the second option because I find the scope_def_t
implementations to be a little hard to understand because of the
optimization code that is in each method.
-Allen
|
