QtScript
Simon Hausmann
hausmann at kde.org
Tue Feb 6 08:57:29 GMT 2007
On Tuesday 06 February 2007 09:27:34 Boudewijn Rempt wrote:
> On Monday 05 February 2007, Richard Moore wrote:
> > Yes, Kross is just a way of instantiating engines - it's pretty
> > trivial. The real effort is in bindings etc. which kross leaves to the
> > engines (including KJSEmbed, QtScript, PyQt, QtRuby etc). Kross is
> > just a little bit of glue.
>
> You don't have to create separate bindings to your application objects for
> each supported language with Kross. Which means does save the effort to
> make separate bindings for every language you want to support. And then
> there's the extra's around it, like the script manager.
>
> So it may be trivial, but it's not just a little bit of glue.
This only works if you wrap every class in a QObject, which is not only very
tedious but also a waste of memory and is slow (remember, QObject destruction
is still fairly expensive due to the multi-threading support). And it means
you have to duplicate the entire API. Kross for example provides a binding
for QColor where every instance is a full-fledged QObject...
Ideally you want to wrap value based types as close as possible to the
language or even implement them in the language itself, for example QPoint or
QSize as structure/object in the language itself and convert to the C++ type
on-demand instead of wrapping every QPoint as QObject...
And on top of that I believe you want to reuse as much as possible of your
existing internal API and use adaptors to slightly adjust interfaces (for
example use different return types for methods that return references to
other objects), instead of duplicating your entire existing API, which is
what you have to do with kross. Just look at kword's scripting plugin to see
what I mean.
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070206/fce985de/attachment.sig>
More information about the kde-core-devel
mailing list