[C++-sig] pyplusplus ui / API

[Roman Yakovenko]

On 2/15/06, Matthias Baas <baas at ira.uka.de> wrote:
> Right, it's still "spaghetti" in a way that you have to define all this
> stuff somewhere, but the difference is that 1) you can keep everything
> related to a particular class together and 2) you can decide to split
> the stuff up into several functions or even modules as they don't depend
> on each other.

1) - very good point

> >> Class module_t will contain declarations_tree property. User will be
> >> able to travel
> >> the tree and:
> >>     to set ignore flag to True or False ( no more confusion )
> >>     to set call policies ( no more call policies factory )
> >>     to set alias
> >>     to set documentation string
> >> and may be few other things, right now I don't have good definition
> >> for "other things"
>
> ...to add new methods (if the declaration is a class).

No, I explained this in other post

> ...to rename arguments or disable the generation of keyword arguments.

yes

> ...to influence the way the declaration will appear in the output file
> (i.e. provide constructor arguments for the corresponding code creator).
> ...maybe to set a "priority" (for influencing the registration order).

No. It is possible to get fully automated solution.


> I haven't had a close look at the code creators yet, but couldn't they
> already be customized by attaching the arguments for the constructor in
> the nodes of the declaration tree? Or are there situations where you
> must work on a code creator instance directly?

Yes. There are some code creators that does not have analogy in
declarations tree.

> test_ns is a node from the declaration tree, right? This raises the
> question if this tree should only represent the *contents* of the Python
> module or also the files and layout of the generated files.
> So far I'm rather undecided about that but I tend to leave it the way it
> is, i.e. the declaration tree represents the module content and the code
> creator tree the content of the generated files.

Exactly. Good point.

> >> 3. Technical problem: pygccxml is stand alone project. It is useful on
> >> its own. I don't want
> >>     to pollute it with code that is only useful for pyplusplus. I
> >> think that next solution will
> >>     work, but I don't like it:
> >>     pygccxml defines next class pygccxml.declaration.class_t
> >>
> >>     pyplusplus will create new class that derives from
> >> pygccxml.declaration.class_t class.
> >>     Lets say it will be pyplusplus.declaration_wrappers.class_t.
> >> pyplusplus will change
> >>     __class__ attribute of pygccxml.declaration.class_t instance to be
> >>     pyplusplus.declaration_wrappers.class_t. Thus user will have
> >> "original" declarations
> >>     tree, full functionality of pygccxml and easy way to find out what
> >> he can\should
> >>     change\set for specific declaration. What I don't like is the
> >> trick, that changes
> >>     __class__ attribute.
> >
> > Why derive a new class.  It seems like you could get by with just
> > injecting the flags/attributes that are needed to specify what the
> > creators should create.  Am I missing something here?
>
> I think what he meant (and what I initially also thought) is to directly
> work on the declaration tree, i.e. all the convenience methods that make
> up the public high level API would be part of the pygccxml classes. You
> could still decide if you use the high level API or if you work directly
> with the low level stuff.
> I was also already thinking about adding new methods to the pygccxml
> classes at runtime to get a high level API. But your way of having
> wrapper classes that are created when needed looks like the way to go.
> This actually separates the data (the declaration tree) from the
> interface (the DeclWrapper classes) which is a good thing in my opinion.
>   This way we can keep pygccxml as it is and add a public API on top of
> it (coincidentally, this is exactly the approach that is used in the SDK
> I'm currently wrapping). We could even try several APIs at the same time
> as they just provide different means for manipulating the declaration
> tree. And these API classes can ensure that the declaration tree is kept
> in a consistent and valid state.

Yes, that is the main idea. But what is the nice way to implement it?

Thanks


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