Re: [pygccxml-development] Printing declarations...

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

On 3/23/06, Matthias Baas <ba...@ir...> wrote:
> I noticed that the selection works differently in your version compared
> to the experimental version. I would have only called it "stable" when
> the interface in both versions would have been identical as in this
> case, it would have shown that we all agree on one common scheme.
> Obviously this is not yet the case.

Why? In my opinion our "select" interfaces are very very similar.
What I am missing. I do aware about differences in regex filter/matcher, bu=
t
that's all.

> I just tried to write a driver script for the Maya module that only uses
>   the "official" module_builder_t class. I thought I could mainly use my
> existing script and only inject aliases for the method names in
> module_builder and decl_wrapper. But it's not only the naming convention
> but also the interface itself that differs.

You right, there are differences, but not the conceptual ones. I can be fle=
xible
( At least I believe so :-) )

> So switching entirely to
> your version would take quite a bit of time and even with my current
> partial script I've noticed things that could be improved in my opinion.

What are they? We can discuss them in few mails and I think we could implem=
ent
them on main branch.

> But at least it provides a basis for further discussion
> (as I just see it as another proposal for an API)

And you are right.

> and hopefully we can objectively
> balance the pros and cons of each version once they're in a state that
> the respective supporters are happy with. :)

That is exactly what I want. I think you and I developed enough. It is a ti=
me
to move on. I think we should sit and merge our sources/ideas.
Do you think that there are some major features that is still missing
in my/your selection code base?

> > Although your implementation is so different from my.
> > I fill a little bit uncomfortable with this.
>
> Yes, we seem to have different ways of thinking and programming... ;-)

Yes we are :-)

> But anyway, the focus is still on the *interface*, isn't it? This means,
> the actual implementation of a prototype interface is not important at
> all (as long as it works and can be used to test the interface).

Yes. So may we close at least select interface?

> For a final implementation (once the interface is stable!), we should
> find better algorithms anyway. For example, querying for declarations
> could be a lot faster (now that the parsing time is no issue anymore,
> querying for declarations has become the new bottleneck for me).
> Currently, we use a rather naive approach of iterating through all
> declarations and applying a filter function which is O(n) for a single
> query. It would be great if a final version could reduce this complexity
> to O(log(n)) or even O(1) by doing some preprocessing. By the way, such
> a thing might also have an effect on the interface itself. If you base
> selections solely on user-provided functions then there's little you can
> do to get any better than O(n). But if you provide a set of predefined
> filter functions then we know in advance how this filters work and can
> exploit that knowledge to speed up the queries.

I also saw performance problems and I think I can fix them without changing
select interface

> > P.S.2 Can you start writing some introduction/tutorial for high level A=
PI?
>
> I'll see that I gradually update the documentation of the experimental
> module. You can then take the parts that are identical and use them for
> your version as well. But I'm afraid I'm not yet able to write a
> tutorial for your version as I'm not entirely familiar with the way it's
> supposed to work and I even think that a couple of things need improvemen=
t.

Please say what are they? As I already said, I am going to be pretty
busy next week,
but at the end of the week we can chat a little, what do you think?

Matthias, I want people to start using pyplusplus. So I think that we
should stop
"code creation" and start merging. Almost all your ideas found the way
into pyplusplus
code. What do you think about next plan: this and next week you are
going to develop
missing functionality.From the 1/04 we close experimental branch and
start merging
almost all functionality to main  branch.

Thanks

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