Re: [pygccxml-development] Status of code inserters

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

On 8/31/06, Matthias Baas <ba...@ir...> wrote:
> In my current implementation the "base" class for the "arg policy"
> objects is called code_block_base_t. But something like
> func_transformer_t or similar is fine with me as well. After all, this
> class is more or less an internal class that doesn't have to be used by
> the end user, its main purpose is to document the interface that the
> user has to implement.
>
> As to the name that is exposed to the user, in the wiki and doc strings
> I'm still using the name "argument policy" as I found it still describes
> the main usages best. All the cases where I want to use this feature for
> my Maya bindings deal with arguments (including the return value =
> output argument), see the use-cases in the wiki.

Does it mean that you agree with proposed name?

>Previously, the only
> exception would have been the thread-safety stuff, but meanwhile I think
> this should not be implemented using the "arg policy" mechanism anyway
> because this is not straightforward to do. Instead, I'd recommend to
> implement that separately.

Can we put "thread safe" aside for a time being? We will come back to it.

> > * Untill this feature, the only classes that generate code were code
> > creators.
> >   Py++ design\architecture is described here
> >   (
> > http://language-binding.net/pyplusplus/documentation/architecture.html ).
> >   I prefer to stay with it, hence I ask you how you see this feature
> > is integrated  within Py++.
>
> The existing Py++ calldef code creators will still remain the code
> creators for the calldefs. What would slightly change is the way *how*
> they create their code, i.e. they would have to add some variables at
> appropriate places to the code and have that variables substituted by
> the proposed text substitution services.

So, the whole feature is to create plug-ins into ( calldefs ) code creators?
Nice :-)

> > * WrapperManager. It is presented in the document as a "Template" class.
> > From my experience it is not possible to build such class without using
> > tons of if-else statements.
>
> What do you mean with "Template" class? Are you referring to the
> template string argument that is provided by the user of the class?
> (this is just an argument name)

String substitution.

> > * Coding convention. I really don't want to introduce

> Uhm, to introduce what?
> I already tried to stick to the Py++ conventions.

Thanks, I pushed "send" button to early :-)

> By the way, yesterday I renamed the "wrapper manager" class and now I'm
> calling it "substitution manager" class. I think this describes the
> functionality better. The actual class name in the implementation is
> "subst_manager_t". The entire sub-package is currently called
> "wrapper_subst".

This is the name I looked for! "substitution manager". One comment: do you
mind to write full package and class names? We always can introduce aliases
in Python. I think that full names are easy for maintenance.

> > * To create design. I'd like to see classes and methods, with
> > responcibility
> >  description. This will give us an ability to split the work. Also we
> > will be able
> >  to take a use case and to see what code user will have to write in order
> >  to apply a transformation.
>
> At the lowest level, there is the substitution manager class (formerly
> known as wrapper manager) which has to be used by the Py++ code creators
> to "enhance" their generated code (see the wiki for examples). Some
> things to note here:
>
> - The modified code might require additional include files. The caller
> (i.e. the Py++ code creators) must ensure that these include files
> actually get included.

I plan something different here: I want to associate include files with classes
and other global declarations. Thus Py++ will generate better code( right now
all cpp files contains includes of the whole project ). This feature
will work for our
case too.

> - There might be some additional support code necessary that is
> generated by the substitution manager. But I think this can probably be
> handled much in the same way as the previous point, so it's not really a
> new point.
>
> - The modified code (at least the wrapper) might have a different
> signature than the original code. The Py++ code creators have to deal
> with this. In particular, it might happen that two overloaded functions
> end up with the same signature.

Not a problem.

> - The user might add "arg policies" to methods that wouldn't have
> spawned a wrapper function otherwise. So the presence of policies is
> already a sufficient condition for the creation of a wrapper function.
>
>
> I have already implemented the substitution sub-package (see the wiki),
> but the integration into the Py++ code is not yet done.
>

I will take a look on it pretty soon.

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