Re: [pygccxml-development] Re: Roadmap?

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

On 3/24/06, Matthias Baas <ba...@ir...> wrote:
> I even think it only takes a couple of minutes. But I think this would
> have been an important thing as it affects the user's script.

module_builder/__init__.py module now imports all necessary functionality.

> In my view there are three "layers" of software involved in the process
> of creating bindings. Here's some ASCII art that shows the layers (make
> sure to use a fixed pitch font for viewing):
>
> +------------------------------+
> |  The user's "driver" script  |
> +---------------------------+  |
> |  High level API           |  |
> +---------------------------+--+
> |  pygccxml/pyplusplus "core"  |
> +------------------------------+

Matthias, I don't want to start theoretical discussion, really.
In general I agree with you.

> Above you say that sticking the relevant stuff into one module is just
> "polishing" the implementation. Here I disagree! This "polishing"
> directly affects the user's script on the very top of those layers and
> as such, I consider it to be a very important issue.

I agree with you, but for me very important issue is something that will ta=
ke
few days to implement. Documentation is one of them, for example.

>Whereas if you
> modify something in the pyplusplus core or within the implementation of
> the high level API, but this modification is not "visible" in the user's
> script then there's actually nothing that needs discussion anyway.

I think you should understand that high level script and user api is
tightly coupled.
Second, sometimes implementation details important - for example performanc=
e.

> > There are few ways to go:
> > 1. You can pass all arguments needed for parsing to module_builder_t.__=
init__
> >     method.

Done.

> >> - The selection functions accept *any* keyword argument even when that
> >> argument is not used/valid at all.
> >
> > Well, all you say is that my implementation has not been polished and y=
ou are
> > right. It is just a concept.
>
> Yes, but missing documentation and missing warning/error message make it
> rather difficult to use. You can neither read how it works nor can you
> apply "trial and error" attempts.

Work in progress

> >> - I think making the step to create code creators explicit is not
> >> necessary. To me, code creators are rather an implementation detail a
> >> user doesn't really have to know about (maybe this will change with mo=
re
> >> advanced features...?).
> >
> > Here I am semi agree with you. I understand your point, but access to p=
owerful
> > features of pyplusplus( code creators ) should be also easy.
>
> When the user needs it he can of course call the function, I'm only
> arguing that it is not necessary to enforce such a call when it is not
> required by the user (which I think is the common case).

Where you will setup module name?

> I *am* implementing the experimental module by using the functionality
> provided by pyplusplus. This has always been the case. I'm not planning
> on implementing my own code generation tool... :)

Honestly, I don't see reuse of functionality except code creators.

> > I am sure your code will find the way into main branch in few hours.
>
> But I never said I wanted the high level API to be part of the main
> branch *as quickly as possible*. It has always been my point in the
> previous mails that I actually like it to be independent and separate
> from the core (as long as the API is still under heavy construction).

I consider API found in pyplusplus as stable. So I would like to insert you=
r
functionality inside. I would like to talk with you and explain every corne=
r
of pyplusplus.

> Didn't I mention that in a mail once? (hm, maybe I wanted to mention it
> but there were more important things at that time...) Anyway, after the
> introduction of the decl_wrappers it took me a while to get the basics
> working again, so during that period of time the more advanced features
> haven't been that important. That's going to change now... ;)

:-). Yes we will merge our efforts.

> >> But there are certainly features missing in the API. See for example,
> >> the section "What capabilites are not supported by the current API tha=
t
> >> we should have?" in the wiki.
> >
> > May be I am looking in a wrong place, can you post the link? Thanks
>
> https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion

Yes, we will add missing features in next releases.

> But just because a piece of code is located in another directory doesn't
> mean it is more stable, does it?

Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP,
boost.date_time and TnFOX ).

>Wouldn't that be kind of a "false
> security" to think that this API couldn't change anymore?

This is not the message I pass to an user. Even API in main branch could be
changed. The main message is that API in main branch has been tested and it=
 is
useful.

>
> > If  I would wait, while I have "perfect" API, I
> > wouldn't get your and
> > Allen help. So lets go for release.
>
> I never said you should not do a release. I'm in favor of a new release!
> I'm only arguing that a new release shouldn't mean the end of the
> experimental module.

Do you plan another revolution in pyplusplus :-)? If no I see no point
in experimental
module.

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