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:
> Roman Yakovenko wrote:
> >> I'm currently trying to support the function transformers on non-virtual
> >> functions (i.e. mem_fun_t). It works fine when the corresponding class
> >> also has virtual functions so that a wrapper class gets created anyway
> >> and there's a place where I can stick the wrapper for the non-virtual
> >> function. But if Py++ does not create a wrapper then there's no "hook"
> >> where I could add the wrapper function.
> >
> > In this case Py++ should create wrapper.
>
> You mean a wrapper class, not a wrapper function, right?

Yes.

> > The code that finds out
> > whether wrapper is
> > needed or not should be moved from the factory (
> > module_creator.creator_t ) to the decl_wrapper.class_t. This is a
> > re-factoring that should be done.
>
> I agree that this refactoring is desirable and should be done, but it
> won't provide a solution to my current problem (only a workaround).
> I only want to make the wrapper function (i.e. a free function, not a
> member function) available in the corresponding source file so that it
> can be referenced in the registration function for the class. I don't
> want to force Py++ to create a wrapper class when it's not absolutely
> necessary.

I prefer to create class wrapper:
1. This will be the consistent behaviour. There are a lot of places,
where Py++ creates
    class wrapper, even if it is not absolutely necessary
2. This behaviour very easy to explain.
3. There is at least one important use-case when this behaviour makes
it easier to
    work with Py++ - integration with already existen code.

> So this either requires something like class_t.add_declaration_code()
> that is also available at the time the code creator tree is built

This is not the way design pattern "factory" works. So the answer is not.

> or a
> way to specify the file that a particular code creator object belongs to
> (personally, I think the latter would be more intuitive and fit the
> framework better as we're already dealing with code that happens after
> the decoration stage).

Not a best solution. I think you missed the trivial solution. Please
read this document
http://language-binding.net/pyplusplus/documentation/architecture.html
and then search for associated_decl_creators string within the package.

Come back  if you need more tips :-).

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