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

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

Roman Yakovenko wrote:
> On 3/22/06, Matthias Baas <ba...@ir...> wrote:
>> That's what I meant in a previous mail when I said I'm in favor of
>> waiting with moving the high level API to the official code until it's
>> more or less stable and all areas have been addressed.
> 
> I don't agree with you on this point. I think that you and Allen did
> such great job,
> really. You designed completely new interface to pyplusplus. I think
> that select api is
> stable. It is not going to be changed, only in a few places we will
> add a functionality
> users missing/need. Don't you agree with me? Please, take a look on py_date_time
> example. You will see the whole power of select interface :-).

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.

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. 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. 
But at least it provides a basis for further discussion (as I just see 
it as another proposal for an API) 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. :)

> 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... ;-)
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).

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.

> P.S.2 Can you start writing some introduction/tutorial for high level API?

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 improvement.

- Matthias -