pygccxml-development

[pygccxml-development] Adding code creators to decl_wrappers...

[Matthias B. <ba...@ir...>]

Hi,

the last "high priority" thing (at least for me) that I was missing was 
the ability to add code creators to declarations, so I gave it a try 
myself and modified pyplusplus.
Here is what I did:

- In decl_wrappers.scopedef_t I added a method "append_creator()" that 
adds a code creator to an internal list (which is made available as a 
read-only property).

- In code_creators.scoped_t I re-implemented the create() method so that 
it first adds the creators from the declaration to the local list of 
creators and then it calls the inherited create() method. I did that 
here and not in the constructor because I thought it's better to add the 
custom code creators to the *end* of the list instead of the beginning.

Roman, is that along the lines as you were thinking to implement it 
yourself? (should append_creator() rather be called adopt_creator() as 
they are already called in the code creators?)
If you have no objections against the above approach I can commit the 
changes.

- Matthias -

Re: [pygccxml-development] Adding code creators to decl_wrappers...

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

On 3/16/06, Matthias Baas <ba...@ir...> wrote:
> Hi,

Before I start, I want you to know that I thought about this feature
from the moment I saw it. It was not clear to me how it should be implement=
ed.
I don't think that code creators and decl wrapper should have cross
dependencies.
This is technical reason. There is another reason: code creator is concept.
Every code creator has parent code creator and only one.  Code creators is
a data structure that have an order. I don't want to mix decl_wrapper and
code creators. I am afraid we will have some requests from the user, we
will not be able to implement with code creators within decl wrappers.
I think I find solution,  while I am writing this mail.

> the last "high priority" thing (at least for me) that I was missing was
> the ability to add code creators to declarations, so I gave it a try
> myself and modified pyplusplus.

In general this is what I expected so much time :-). Also does it mean that
you use module_builder_t class and you more or less happy with it's interfa=
ce?

> Here is what I did:
>
> - In decl_wrappers.scopedef_t I added a method "append_creator()" that
> adds a code creator to an internal list (which is made available as a
> read-only property).

I prefer add_text, where add_text defined as

def add_text( self, text, works_on_instance=3DTrue ):
    self.additional_text.apend( class_text_t( text,  works_on_instance ) )

where class_text_t is next:
class class_text_t:
    def __init__( self, text, works_on_instance ):
        self.text =3D text
        self.works_on_instance =3D works_on_instance

If you take a look on code_creators/custom.py you will find class very
similar to
this one. But that one is real code creator. May be I choose bad name, but
I hope you've got the idea. Also you can suggest your name, but it should
not contain "code creator" words. :-)

> - In code_creators.scoped_t I re-implemented the create() method so that
> it first adds the creators from the declaration to the local list of
> creators and then it calls the inherited create() method. I did that
> here and not in the constructor because I thought it's better to add the
> custom code creators to the *end* of the list instead of the beginning.

You have 2 little mistakes here, sorry :-(
1. You can not add them from the constructor. module_creator.creator_t
class does not create all internals code creators before external one.

2. Why do you want to give an user only one place, where user can add
custom text? For example in class_text_t you can add new argument - positio=
n.
Thus user will be able to say position, relative to code creators. I
don't ask you
to implement this behaviour, but I think you should be aware about new futu=
res
the user  can ask for.

> Roman, is that along the lines as you were thinking to implement it
> yourself? (should append_creator() rather be called adopt_creator() as
> they are already called in the code creators?)
> If you have no objections against the above approach I can commit the
> changes.

I am not sure whether we should change code_creators.scopedef_t and
decl_wrappers.scopedef_t classes. You can not add new code to
namespace.
There is no such thing in code creators policy right now. Also, If I rememb=
er
right all your use cases is to add new code to some class, right?
So, I prefer you will change decl_wrapper.class_t. I think we should add 2
lists here. The first one will contain code for boost::python::class_ code.
And the second will contain code for class wrapper. I think it will cover 8=
0% of
cases, when and where user need to add some code. Also I think we should
add an other 2 lists for module and module body. Thus user will be
able to modify
"main" function and code before it.

Also I think that you should not touch create function. Really, the
better approach
it to override code_creators.compaund_t._get_creators function. It will ret=
urn
new list, that contains from real code creators. You will create custom_tex=
t_t
code creator on fly.

> - Matthias -

What do you think? Please critic this solution. If you agree with this solu=
tion,
can you implement it and commit?

Thanks


P.S. Do you see the hour I sent this message? - As you can guess
I have Internet at home.

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

Re: [pygccxml-development] Adding code creators to decl_wrappers...

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> Before I start, I want you to know that I thought about this feature
> from the moment I saw it. It was not clear to me how it should be implemented.
> [...]

I realized I'm still missing the "global view" on the implementation of 
  pyplusplus and that my approach was too short-sighted (for example, I 
totally neglected that someone might want to add stuff to the class 
wrappers) and I agree that a more general mechanism should be implemented.
However, I'm afraid I'm not able to implement that myself yet as your 
explanations contained some stuff I'm either not familiar with or I 
don't see how a concrete implementation would look like.
But as I do have a working solution for the moment, I can live with that 
until the "official" version is in. I suppose it would also be no big 
deal to move the (limited) functionality that I currently need to the 
high level layer, so that I can again use the same version of pyplusplus 
that everyone else is using as well (instead of having a "private" branch).

> In general this is what I expected so much time :-). Also does it mean that
> you use module_builder_t class and you more or less happy with it's interface?

I'm still using the module builder from the experimental module.
But I did notice that you've added the selection interface to the 
appropriate decl_wrappers.

> P.S. Do you see the hour I sent this message? - As you can guess
> I have Internet at home.

Ah, welcome back to the online community! :)

- Matthias -

Re: [pygccxml-development] Adding code creators to decl_wrappers...

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

On 3/17/06, Matthias Baas <ba...@ir...> wrote:
> I realized I'm still missing the "global view" on the implementation of
>   pyplusplus and that my approach was too short-sighted (for example, I
> totally neglected that someone might want to add stuff to the class
> wrappers) and I agree that a more general mechanism should be implemented=
.

If you want I can find some time to explain you design and main concept of =
C++.
I mean we can chat on irc, from my home computer :-)!

> However, I'm afraid I'm not able to implement that myself yet as your
> explanations contained some stuff I'm either not familiar with or I
> don't see how a concrete implementation would look like.

I will try to commit first version on Sanday or Monday.

> > In general this is what I expected so much time :-). Also does it mean =
that
> > you use module_builder_t class and you more or less happy with it's int=
erface?
>
> I'm still using the module builder from the experimental module.
> But I did notice that you've added the selection interface to the
> appropriate decl_wrappers.

and to the module builder itself.

> - Matthias -

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