[Kde-bindings] Bindings...

[Richard Dale]

On Tuesday 18 February 2003 3:01 am, Ashley Winters wrote:
> I managed to come up with an outline for what I plan with my particular
> C interface for Qt/KDE.
>
> First thing, prototype mangling is out the door. I'm going to cheat on
> that one.
>
> void QApplication::exec(int retcode = 0);
>
> That will get two functions in C:
>
> exec_1_wtS6
> exec_2_LmeL
>
> It's easy enough to sketch what those functions will look like.
>
> extern "C"
> void exec_1_wtS6(void *a1) {
>     ((QApplication*)a1)->exec();
> }
>
> extern "C"
> void exec_2_LmeL(void *a1, int a2) {
>     ((QApplication*)a1)->exec(a2);
> }
>
> The format of the C functions names is interesting.s 
>
> 1. method_name
> 2. argument count
> 3. first 4 letters of the base64-encoded md5sum of the method prototype
> being interfaced. Of course, all illegal characters are replaced with
> '_'. Operators will get their gcc-standard names.
>
> Fun, eh? No name mangling for me.
He he - 'wtS6' just jumps out of the page at me :) But the only advantage I 
can see of using a checksum is to save on the length of the function names. 
Why not just have something like '<class name>_<method name>_<args type 
signature>'? Wouldn't that make debugging easier - 14000 method names with an 
extra 10 bytes each would add 140k to the Qt/KDE bindings libs.

> As for handling virtual functions, that's handled pretty simply too
Well, I'm keeping a close eye on this use of the 'simply' adjective..

> First, you need to get the global virtual function table for a class:
>
> extern "C" void *virtual_get_QWidget();
>
> Note: that's not the REAL virtual function table I'm using. Just a
> parallel one. I'm not going that far off the deep end...
What are all these new 'virtual hook' methods in KDE - are they something that 
can be used for language bindings callbacks?

I like the smoke idea of communicating callbacks via a stack, because it means 
you only need one type of delegate which is passed a reference to the stack. 
Otherwise you need a bazillion different types of callback/delegate for each 
possible virtual method argument type signature.

> Then, for a language like C#, you would override a method using a
> delegate pointer passed to a override_ prefixed method with the above
> prototyping system. Like so:
>
> // Overrides QWidget::setMask(const QBitmap &) with delegate
> extern "C"
> void override_setMask_2_piWT(void *vtable, void (*delegate)());
>
> That delegate would get called with all the arguments passed to the
> virtual function, with speed penalty.
>
> For PerlQt, we would add a level of indirection. There would be a
> separate function for marshalling the virtual function arguments, and
> that function which marshalls the arguments would be passed to the
> above function.
>
> The XML file would contain the method signature used to generate the
> MD5sum, as well as the 4-letter sum used for the method. This would
> allow binary compatibility with client libraries between upgrades to
> Qt/QtC, since the method names never change.
>
> This isn't meant to be used by programmers, only by language bindings.
>
> Also, the C library will keep a global table of pointers created, since
> as far as I know every language binding needs that. In fact, the C
> binding will need it as well, since I'm thinking about supporting
> per-object virtual function tables! Whether I could do this without a
> global speed penalty is another question...
>
> Indeed, that means you could create singleton widgets like this in
> PerlQt in the future:
>
> $w = new Qt::Widget(this);   # vanilla widget, not a subclass!
> $w->virtual->{mousePressEvent} = sub {
>     my $e = shift;
>     printf "You clicked at %dx%d\n", $e->x, $e->y;
> }
Nice - that would be good for implementing Objective-C categories that can 
both add to and override existing behaviour of an existing instance without 
subclassing, or for ruby mixins..

> Yes, I'm crazy. It's fun, though.
Well as far as I'm concerned, lets have more of that bindings madness..

-- Richard