[Kde-bindings] Blowin' smoke your way

[Ashley Winters]

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