[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] The code!
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2003-03-08 19:57:13
[Download RAW message or body]

On Friday 07 March 2003 8:01 pm, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale@tipitina.demon.co.uk> wrote:
> > * 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'.
>
> Okay, how about a compromise?
>
> The -fdump parser is limited in reconstructing default values. It can
> retrieve constants from gcc just fine, and even variables, but
> expressions aren't going to happen. Therefore, I can offer this:
>
> Add an 'artificial' flag to all generated methods which were created
> for the purpose of making bindings easier (non-defaulting arguments,
> baseclass virtual methods, etc). That way, it's very easy to wean them
> out.
>
> For the non-artificial methods, go ahead and extract whatever default
> arguments it's possible to extract as a "value" tag.
>
>     <method protection="public" name="QWidget" type="constructor">
>       <argument name="parent" type="class QWidget*" value="0" />
>       <argument name="name" type="char const*" value="0" />
>       <argument name="f" type="bool" value="0" />
>     </method>
>
> Constant integers, enums, and boolean variables should all work as
> value. Whenever a value in indecipherable, I will use value="?", and
> it'll be up to the language binder to figure out what to do with that
> one. Perhaps there will be so few of them we could hard-code values in.
> Fortunately, QWidget wouldn't have any value="?" defaults.
That's fine - if the value of the default is undefined, multiple JNI functions 
would be generated for java, otherwise if the value is defined, a single JNI 
function and several java methods with the C++ default values translated to 
their java equivalents. I think there would be relatively few cases of 
undefined values, so any extra library size overhead wouldn't matter much.

> > 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.
>
> Very good point. I will keep that in mind. (Although, if you wanted a
> small JNI library, there's always Smoke. *cough*)
Yes, I intend to do the virtual method callbacks for java just like the smoke, 
passing a stack reference plus numeric index into an array of method 
signatures. It maps very straightforwardly onto the array of classes/values 
that java method invocation via reflection expects. I could easily use that 
part of of the smoke library. And being able to call protected methods is 
another thing that non-scripting languages need, and smoke has.

But it isn't possible very easily in java to implement the way perl and other 
dynamic languages can forward a method invocation to a native method if the 
perl method isn't found - java and other non-scripting languages couldn't use 
the other half of smoke.

Perhaps split smoke into two libs - a virtual method callback/protected method 
call part with C interface (PUFF? - 'Pretty Universal Function Forwarding', 
tee hee :) ), and a second lib with the scripting language specific stuff, 
er.. SMOKE as before. 

> > * Class hierarchy
> > How is this represented in the XML - each class would need something
> > like a
> > 'parents' attribute with a list of parent classes?
>
> <base> tag, actually. The Perl hashes randomize its location in the
> file. On my computer, it's happily placed at the top of the XML file.
Ah ok, good - didn't spot that. It can have more than one entry for multiple 
inheritance I assume?

> > * 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.
>
> Browsing through the Qt documentation, I've decided that it would
> actually be an excellent way of specifying what classes to place in the
> XML.
>
> grep '\\class ' *.cpp
>
> As you can see, that is a rather comprehensive list of classes
> implemented & documented in those source files, along with the header
> to parse to get -fdump info if I wanted to list them.
>
> The qdoc standard requires \fn OR the first line after the end of the
> qdoc comment to be the method signature? Works for me. I think I could
> parse one line of C++ per function, just this once. I think I can
> squeeze in qdoc next version, no extra charge.
>
> I'll do that document extraction in a separate program though. XML is
> too convenient to not use as an intermediate data format. :)
Could the qdoc/kdoc comments be converted to XML in the style of C# document 
comments, so they could still go in with the rest of the XML? As long as I 
could get back to javadoc format from the XML one (at the moment kdoc 
converts quite straightforwardly to javadoc).

> I might even stick the signal/slot detection in another script as well.
>
> Hell, I'll just make the 'artificial' method generation use that same
> trick, and take that cruft out of the -fdump parser. It'd be cleaner
> that way.
>
> > * Argument names
> > They're there - excellent!
>
> Yes, very handy. Not only there, but required!
>
> > 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.
>
> Yeah, templates aren't a big loss. I'm rather stunned at getting
> QString/QChar and all the other utility classes working in one shot,
> though. Last night, I did an XML dump of the whole Qt include/
> directory. Enlightening stuff.
I hope you didn't read it all.. Are there any problems with the KDE dump info 
- does it allow fully qualified class and namespace enclosed names, for 
instance?

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]