I've been thinking about how best to use this stuff for improving the java 
bindings code generation. It solves two problems - extracting bindings info 
from an -fdump'd file more accurately than by parsing headers, and producing 
XML in a standard format. 

I don't personally have a requirement for the second XML bit. I think my 
actual requirement is to be able to pull together bindings generation data 
from several different sources. For example, I'd like to get C++ method 
signatures via '-fdump', C++ signal/slot or kde dcop signatures via command 
line utilities, Qt doc comments from the .cpp sources in qdoc format, and the 
KDE doc comments from .h headers in kdoc format. Then pull them all together 
into a common tree, which I can use to drive the production of the final 
code.

If the XML format helps with this 'data merging', then it would be useful. But 
if it turns out easier to do it another way, I'll use that.

* Default argument values
You're producing a different xml method description for each possible number 
of arguments. For java, it would be more useful to represent these as a 
single method with the maximum number of args, and an additional couple of 
attributes added for each arg 'is default arg' and 'default arg value'. 

This would allow the generation of a single native code JNI call with the 
maximum number of args, and the other method calls with fewer args would be 
produced by generating java source code. JNI calls take up more space in a 
shared lib, relative to java method calls in .jar file so it pays to try and 
minimise them.

* Class hierarchy
How is this represented in the XML - each class would need something like a 
'parents' attribute with a list of parent classes?

* Document comments
If you're pulling in data from different sources - both '-fdump' and 
slot/signals command line utility so far, then why not use the headers or 
sources as another source of bindings data to extract doc comments, default 
arg values or anything else that is still missing? A text 'doc comment' 
attribute against each method/class would be useful to hold any comment text, 
even if it isn't used by the '-fdump'er' output.

* Argument names
They're there - excellent!

On Friday 07 March 2003 4:30 am, Ashley Winters wrote:
> Okay, new version.
>
> Fixed in this release:
>
> * Virtual functions are declared according to spec. Virtual methods
> inherited from parent classes are indicated with origin="QBase" instead
> of whatever I originally proposed
Is it slightly more efficient to call the actual method on the inherited 
class, rather than allow virtual method despatch to call the method on 
'this'?

> * Fields work. Member variables and static variables in a class are now
> output as field tags.
>
> * Works better. Every class I've thrown at it works beautifully.
> QString, template classes, deeply nested virtual hierarchies. I can't
> find anything wrong.
>
> * Enums work better. Previously, it was only printing out enums
> actually used at arguments to a function. Now it prints out all enums.
>
>
> Missing features:
>
> * Signal/slot tags. I need to integrate slotnames.cpp into the xml
> generator.
We could do something similar to extract KDE dcop methods perhaps.

> Give it a try. See if there's a class it doesn't work right on. I've
> been throwing lots of classes at it... The fact that QString and
> QPointArray (aka. QMemArray<QPoint>) will be fully available to the C
> binding scares me! :)
I fixed up and added the methods from the parent template class by hand for 
QPointArray in the java bindings. Nearly all the other C++ list classes were 
translated into java ArrayLists, so they didn't need any list handling 
methods from the template classes that implemented the lists. QPointArray has 
more to do with handling QPoints than just being a straightforward list 
thing, so it's a bit unusual.

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-bindings