[Kde-bindings] Splitting up the SMOKE library

[Richard Dale]

On Wednesday 18 July 2007, Dongxu Ma wrote:
> Hello Richard, CC: gents,
>
> Beside object bus, how do you deal with allocation of Qt/Kde object ?
> First I'd like to share you my progress on my QT4 Perl binding. Due to
> personal issues, I recently didn't pay much time on coding...
> The typemap system is almost finished. You can check here (
> http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl)
> The typemap, as you know in perl, is the repos for type marshalling between
> perl and c++ plants. While the old typemap mechanism introduced by
> ExtUtil.pm is somewhat out of date, it has no knowledge about relationship
> between relevant types. Say, for instance, QString and QString *. Typemap
> simply treats them as un-relevant ones.
> What I did in tha script is a knowledge study and relationship analyse
> system. For above example, in case it knows QString is a QObject (obviously
> from qstring.h), it automatically knows how to marshall QString *, QString
> &, const QString, const QString * and QString const *. Furtherly
> QList<QString *> is possible. It goes thru different aspects to find type
> relationship ( class declaration, inheritance tree, namespace path,
> pre-defined typemaps ).
> It is powerful enough to bridge native Qt type with KDE type, custom type.
Well I think we already have this sort of thing in the Smoke libs, and we have 
a parser written in perl with powerful abstract syntax tree utilities for 
walking round the parse tree.

> While the bad situation I am facing is GC system. Perl uses simple
> reference, while ruby makes use of mark and sleep way. On the another hand,
> generally, various cases may mess GC:
> 1) GC in Qt itself: Qt maintains its internal object reference status;
> 2) non-new method which exports an internal address,which will have the
> same lifecycle of exporter;
> 3) non-new method which returns a new heap address, which transfers the
> ownership of that pointer to caller;
> 4) non-new method which accepts a pointer and takes the ownership of that
> pointer;
>
> Either case will leak the vm unless treating it carefully.
> I'd like to hear your words on this question.
The Smoke bindings have a struct like this:

struct smokeqyoto_object {
    bool allocated;
    Smoke *smoke;
    int classId;
    void *ptr;
};

Where 'allocated' is true if the instance was created in the bindings 
language, and so the bindings runtime is responsible for deleting the C++ 
instance on garbage collection.

The bindings runtime needs to know about the various rules of object ownership 
in the Qt libraries such as the QObject object tree where a parent 'owns' its 
children and is responsible for deleting them.

The QtJambi bindings have a third state, which is 'not owned by either c++ or 
the bindings language'.

> PS: boost python binding page also discussed similar issues. Go and take a
> look.
What will it tell us that we don't already know, and what do you think is 
wrong with out existing approaches?

Note that the subject of this thread is 'splitting up the smoke libraries' - 
please can you start a new thread to discuss anything which isn't about that 
topic?

-- Richard