Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Hm, so in addition to implementing the actual mem_fun_transformed_t and
> mem_fun_transformed_wrapper_t classes I have to modify code at the
> following locations:
>
> - code_creators/__init__.py: Modify guess_mem_fun_creator_classes() so
> that it returns the transformed versions when appropriate.

This function should me moved to create module_creator package and yes,
you will have to modify it

> - module_creator/creator.py: Modify creator_t.visit_member_function() so
> that it adds the appropriate code creator object to the list of
> associated creators for the current class.

Yes

> When the option is turned on that Py++ should always create a wrapper
> class I also have to modify the following places:

"Turned on" means: there is at least one FT

> - module_creator/creator.py: Modify either creator_t.visit_class() or
> creator_t._is_wrapper_needed() (or both?) so that a wrapper class is
> created when there's a member function that has function transformers
> assigned to it.

I think _is_wrapper_needed will be enough. Although I should move this function
to decl_wrappers package with explanation, why wrapper is needed.

> I think this is rather complex and what I don't like about it is that
> code that belongs together is scattered over several files (even from
> different sub-packages).

I don't think that this code "belongs" together. Think about this:
creator_t class solves "location" problem - where the generated code
should be logically
written, while code creators answer the "what" question - what code
should be created.

> I would really prefer if I could keep all my
> code local to the place where the member function code creators are
> implemented. This would simplify maintenance.

Not for me, because the responsibilities will be less clear more over
it will be difficult
to diagnose the problems.

> For example, the visit_member_function() method could invoke an
> initialization method on the code creator that allows that method to do
> the work that would otherwise be located in visit_member_function().

1. Every code creator has __init__ function
2. The only job any code creator should do is generate code. It is not
allowed to modify
    the tree, more over it is not allowed to do something else.

> Then it would be nice if it was possible to register functions that are
> invoked by guess_mem_fun_creator_classes() and that can check if they
> know how to handle a particular declaration, etc.
> So all in all, it would be great if everything would be a bit more
> extensible so that a modification like the one that I'm currently trying
> to do could even be done externally without having to modify internal
> Py++ code.

If you want to extend creator_t you will have to derive from it or to
modify its
implementation. This is the right way to do it. Please read one more
time the document,
that describes the architecture. Py++ consists from few simple and
dummy concepts. This
is the real power of it. This is your first time you add feature that
works with code creators.
I am sure that in few days you will appreciate the design.

> Or in my case where it actually is an internal modification,
> everything could be kept local to one file (or at least one sub-package).

After moving guess_... to module_creator everything will be in a
single sub-package.

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