[Kde-bindings] Smoke-based versus Jambi-based bindings: what's the difference?

[Richard Dale]

On Tuesday 25 August 2009 01:42:56 am Gábor Lehel wrote:
> I was idly wondering the other day, about how some languages have Qt
> bindings based on Smoke, whereas other languages have bindings derived
> from QtJambi, and that which languages have which appears to depend
> primarily on the principle of "who got there first".
>
> As far as I know, the following languages have bindings based on
> Smoke: Ruby, C#, PHP, Perl;
and Common Lisp..

> and the following languages have bindings derived from Jambi: Java,
> QtScript, D, newly Python (previously/also SIP-based)
Well they use one or other of the C++ parsers written by Roberto Raggi to 
parse the Qt headers, along with XML files of metadata and code to inject. The 
code they generate is all different.

And a Lua binding based on cppxml data is also being written - it doesn't use 
any of the QtJambi family of parsers though.

> And now with Arno Rehn's Summer of Code project and the Bindings
> Generator released as part of the PySide project, we even have
> automated generators for both kinds of bindings.
Yes Arno's generator was also based on the QtScript generator that was derived 
from the QtJambi one, but with the parser from KDevelop4, that is part of the 
same family of parsers.

> So my question would be, purely out of curiosity, as someone who
> hasn't delved into the implementation details of either: is there
> anyone who has familiarity with both bindings systems who could
> explain what the significant differences between them are, and perhaps
> what advantages and disadvantages are entailed by choosing one over
> the other? (Or perhaps one is inherently better suited for some
> languages, while the other for other languages? Given that Java and C#
> as well as Ruby and Python are both split neatly one to each, this
> isn't obvious.)
>
> (The extent of my knowledge is approximately that, as far as I know,
> the Jambi variants first generate C bindings, and then bindings for
> the C bindings for the target language, whereas Smoke looks things up
> in a hash map or something, but that's about as far as it goes.)
The smoke bindings are 'dynamic bindings', in that they share a common library 
and make queries for methods that they want to call. With the other 'static 
bindings', the code to call a bindings method is all wrapped up with language 
specific marshalling at code generation time. Smoke is very similar to how the 
Qt moc (meta object compiler) works, but on a larger scale. For instance, if 
your class has slots, then they can be called by QtScript without you needing 
to do an extra work. There is enough information in the QMetaObject associated 
with the class for QtScript to know how to call the slots. So with Smoke you 
can do the same as that, but for the entire api, not just slots.

> (And obviously one big difference is that the Smoke-based bindings
> also tend to bind KDE, whereas I haven't heard of any of the
> Jambi-using ones doing so.)
Because the same Smoke libraries are used by different language bindings it is 
easier to produce KDE bindings becaues we only have to do it once. The other 
bindings have to wrap the KDE classes for each individual language. The way 
you think about the design of a runtime environment which is shared by 
multiple languages is different. The smoke languages are designed to work well 
together in KDE apps, and allow you to write an app in C#, along with plugins 
in Ruby for instance (we're still working on that, but it is what we want to 
do for KDE 4.4).

-- Richard