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

[Gábor Lehel]

Ah. So the main difference is being static vs. dynamic. That makes
sense. Thanks for the explanation.

The planned cross-language interaction sounds pretty interesting.

On Tue, Aug 25, 2009 at 11:54 AM, Richard Dale<rdale at foton.es> wrote:
> 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
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>



-- 
Work is punishment for failing to procrastinate effectively.