Re: [pygccxml-development] recursive import trick

[Roman Y. <rom...@gm...>]

On 7/26/06, Allen Bierbaum <al...@vr...> wrote:
> 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.

The problem is not in the user space. I did not filled comfortable to
import namespace.py and class.py from scopedef.py.

> Assuming you are interested in removing this hack,

Yes, I am. I am glad you raised this problem.

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

I have mental problem with this solution :-).

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

And I agree with you. If I remember right, I thought about this solution, but
for some reason, decided not to implement it. Definitely I will have
to reconsider
my decision.

I am not going to change this before next release. This change is too big.
And I still need to implement 2 features + documentation. Sorry.
May be you can prepare patch? I will apply it after release.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/