[Kde-bindings] Blowin' smoke your way

[Richard Dale]

On Wednesday 10 September 2003 19:13, 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
> 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. :)
I was assuming the URI strings would be a keys to a hash containing function 
pointers that were the methods, and the could be populated at startup.
> 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'm not sure what you mean here - we're still going to need code that walks 
through a C++ list, converting it to a ruby array and so on. How will the new 
setup improve things?

> > 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).
Objective-C is a dynamic language, and I'm slightly upset to see it mentioned 
in the same sentence as Ada :) - Objc will use the high level autoload style 
interface via -[NSObject forwardInvocation:]. And java can do it too via 
proxies. And I think C# could with RealProxies.

Here's some code from RubyCocoa, an excellent ruby binding:

- (void)forwardInvocation: (NSInvocation *)an_inv
{
  DLOG1("forwardInvocation(%@)", an_inv);
  if ([self rbobjRespondsToSelector: [an_inv selector]]) {
    DLOG0("   -> forward to Ruby Object");
    [self rbobjForwardInvocation: an_inv];
  }
  else {
    DLOG0("   -> forward to super Objective-C Object");
    [super forwardInvocation: an_inv];
  }
}

See how you can either forward the message to ruby, or onto Objective-C - 
pretty good stuff - not static at all!

> 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. :)
Excellent!

-- Richard