[Kde-bindings] Re: JSmoke architectural questions

[Ian Monroe]

2010/10/26 Sven Aßmann <sven.assmann at lubico.biz>:
> Hello @All
>
> i have reviewed a few lines of code from the jsmoke project from git.kde.org,
> and now i have questions about the architecture of the jsmoke project and
> about a design question for the new phpsmoke project.
>
> 1. Is it right that the main core (jsmokeruntime) build the baselevel without
> concrete bindings to any module?

I don't follow.

> 2. the concrete modules are structures under "bindings" and are some kind of
> plugins (QScriptExtensionPlugin)?

yes

> 3. what about the loading of the plugins, is this doing at runtime by
> something like an "import" derective in the qtscript (i'm know not much about
> qtscript)?

Right exactly. You can import QtCore, QtGui, QtXml, all separately.
They map to the underlying Smoke libraries. The purpose of breaking
this stuff up (all the Qt smoke stuff used to be in one library) was
to decrease memory usage and load time by only loading the modules
that are needed.

> 4. is this seperation into plugins only a nice special way because this
> mechanism is enabled by the qt framework itself for qtscript?

Yes, its using the Qt plugin facility. But I mean, having loadable .so
plugins is a pretty standard feature. And like I said, it has to do
with how Smoke itself is split up.

> conclusion
>
> i'm not sure if i can restructure the php bindings project like this, because
> then i have to write an own loading mechanism for the php smoke runtime, that
> allow to import so little nice plugins for any kind of binding into the php
> language.
> in fact php 5.3 support namespaces und imports (or in cpp usings), so it would
> be an really nice benefit if we can do things like this:
>
> <?php
> namespace QtGui\QTextEdit;
> namespace QtGui\QDockWidget;
>
> ?>

...but having separate .so's for all classes would obviously be madness.

Ian