[Kde-bindings] Blowin' smoke your way

[Richard Dale]

On Monday 08 September 2003 08:55, Ashley Winters wrote:
> Howdy all,
>
> I thought I'd toss you an update as far as where Smoke v2 is headed. I
> have... changed my mind a few times since this experiment began. :)
>
> Without further ado, go ahead and take a look at the state-of-the-art
> XML representation (it's an RDF serialization, but I digress) of a few
> functions in QWidget (they're toward the end).
>
> http://perlqt.sourceforge.net/briefstandard.xml
>
> It's not a hierarchial XML tree like past formats. Instead, each tag is
> describing a single function/class/whatever in the smoke 'space'.
>
> Oh, and for a quick primer as to what in the heck RDF is supposed to
> mean, allow me to translate into Perl.
>
> 1: <Foo rdf:about="something">
> 2:    <bar rdf:resource="whatever"/>
> 3: </Foo>
>
> Any tags which begin with a Capital letter are classes, and can be
> thought of as a class in a perl-sense. An rdf:about attribute specifies
> the actual object which is a member of that class.
>
> Think of line 1 being the moral equivalent of:
>
> bless $something, 'Foo';
>
> Any lower-case tags should be considered like hash keys. So, line 2 is
> the moral equivalent of:
>
> $something->{bar} = \$whatever;
>
> That also points out the meaning of rdf:resource in referring to some
> other object (by reference).
>
> Of course, in RDF all these objects/keys/values are called
> subjects/predicates/objects, and all have ridiculously long URIs as
> names instead of $something or $whatever. However, it's simple enough
> to think of them that way for our purposes
>
> Well, that's enough of that. Don't stare at the XML too hard. I don't
> want people getting a headache over something I'm liable to change
> radically again anyways. Anyways, it makes a pretty graph.
> http://perlqt.sourceforge.net/briefstandard.svg
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? 

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?

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? 

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);
	}

	// Optimized smoke v2?
	public QStyle setStyle(String arg1) {
		return proxyQWidget().setStyle("&smoke;QWidget/setStyle(QString*)", arg1);
	}

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?

-- Richard