[Kde-bindings] Blowin' smoke your way

[Adam Treat]

Have you given thought to a unified way of dealing with Qt <--> binding 
inheritance?  I ran into a pretty fundamental barrier with the Qt# bindings 
where I could not reliably inherit and override Qt/C++ virtual functions in 
C#.  The collective marshalling, redirections and method prototypes was just 
to much for the binding to handle.  I have been lurking and watching you and 
Richard waiting for some breakthrough bindings technology...  let me know if 
you have anything interesting in the way of handling Qt virtual functions and 
inheritance for bindings.

On Wednesday 10 September 2003 02:13 pm, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > On Monday 08 September 2003 08:55, Ashley Winters wrote:
> > > http://perlqt.sourceforge.net/briefstandard.xml
> >
> > How does this fit into the final scheme of things - will these
> > descriptions be
> > used to generate runtime code for Smoke v2, or are they there just to
> >
> > describe services available at runtime, and used at runtime?
>
> Umm... I would highly recommend against using the XML/RDF at runtime --
> unless you're integrating with KDevelop or something.
>
> The XML/RDF is for tools to autogenerate code; either the smoke/mirror
> libraries, or a compiled Java interface to them.
>
> The backward-incompatible runtime feature of Smoke v2 will be the
> hiding of the integer IDs. Instead of having direct access to the
> internal integer IDs, you will get an opaque pointer to something,
> somewhere which will represent the URI you requested. How that is done
> is... going to be interesting. :)
>
> Also in Smoke v2, marshalling functions will be deprecated in favor of
> calling class functions directly from the binding language. Only the C
> base types (bool/int/double/etc) will be directly marshalled;
> everything else will be accessed through accessor functions/member
> variables/other things accessable through Smoke. You get to marshall
> QMap<QString,KFont>  however the heck you want.
>
> > I assume the XML generated by the translation unit dump will be
> > transformed
> > into this style of RDF, and then transformed again into C/C++ code
> > generation
> > for the Smoke runtime. And then further services would be added to
> > the RDF
> > database, such as the location of documentation, wikis and so on?
>
> Exactly. I expect various metadata such as requiresVersion and
> requiresPreprocessorDefinition to be included in a sort of 'annotated
> Qt API' collaborative wiki or something which could be distributed as
> part of PerlQt as the 'default' config which could work without using
> -fdump, as well as allowing people to generate their own XML using the
> same script which generated the original. At least, that's what I want
> to have happen. :)
>
> > Will the change to the runtime from a Smoke adaptors point of view be
> > that a
> > method selector would no longer be an int, but a long string?
>
> From int to pointer. You can get that pointer from the long string,
> though. Depending on the implementation, it may be faster to cache the
> pointer instead of passing the string every time. I don't know yet.
>
> > I'm quite close to trying a Hello World with the smoke based java
> > bindings,
> > just need to do more work on the marshalling handlers. But what I'd
> > thought
> > of doing with Smoke v1 was adding the 'munged method/arg types'
> > string like
> > 'setStuff#$' and so on, as the first argument to
> > InvocationHandler.invoke(),
> > the java equivalent of perl autoload or ruby method_missing. Then
> > with Smoke
> > v2, I could generate one of these URI's instead:
> >
> > 	// Initial smoke v1:
> > 	public QStyle setStyle(String arg1) {
> > 		return proxyQWidget().setStyle(arg1);
> > 	}
> >
> > 	// Optimized smoke v1:
> > 	// (Not a good idea to generate an int 1..7000 or so here for the
> > smoke
> > 	// method id, as that would be a bit fragile)
> > 	public QStyle setStyle(String arg1) {
> > 		return proxyQWidget().setStyle("setStyle$", arg1);
> > 	}
>
> Hrm. The setStyle$ style method names will still be available, but not
> as part of the low-level smoke library (called mirror) anymore.
>
> [ libqt-mt.so ]   target library
> [   mirror    ]   low level interface  =>  JavaQt
> [    smoke    ]   high level interface =>  PerlQt and RubyQt
>
> The mirror library provides access to library functions using the URIs,
> and not much more.
>
> The smoke library provides all the method lookup voodoo, like
> setStyle$, which is needed for Perl and Ruby to do their dynamic method
> lookup. In essence, the new generated smoke library will be a giant
> lookup table for autoload-based languages. Compiled languages will be
> expected to "compile" that information from the XML/RDF directly into
> the binding interface (argument 1 is ALWAYS a QString*, and I know that
> for certain because this is Java, C#, Ada, or ObjC; therefore, I don't
> need smoke to tell me).
>
> If a language can know at compile-time the exact C++ method it should
> call, then it should use mirror directly and skip the smoke overhead.
>
> > 	// Optimized smoke v2?
> > 	public QStyle setStyle(String arg1) {
> > 		return proxyQWidget().setStyle("&smoke;QWidget/setStyle(QString*)",
> > arg1);
> > 	}
>
> Yes, that's the idea. There may be caching tricks which may make it run
> faster, but that's for testing to decide.
>
> > So given the URI, it should be fast to call the Smoke runtime, as the
> > string
> > would be the key to select the method. Does that seem a good idea?
>
> Yes. :)
>
> Ashley Winters
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-bindings