[Kde-bindings] GC system inside kde-bindings

[Dongxu Ma]

>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.
Nice. I used to have a look at Smoke, the output is quite programmatic look
(in C),
that is one of the primary reasons I'd like to write QTEDI, which presents
in more
human-readable style. While that doesn't mean Smoke is ugly, really depends
on
how people make use of.
>
>> 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'.
The hard point here is the handover of object relationship is really case by
case.
The metaobject system in Qt is mainly based on class inheritance hierarchy.
That doesn't really work for the case: the instance exports an inner part
(note
that such part is in-a-class, not is-a-class); while other method may export
a
component of itself, which is certainly a standard QObject, and release the
ownership of that component to caller; From my point of view, it is very
hard to
tell such two different cases automatically.
Another example to address one of my previous points: say, one creates a new

QObject in binding code, then QObject is owned by binding code till a
special
method is invoked, which takes that QObject as parameter and finally 'eats'
it.
That dedicated QObject is taken over by Qt metaobject after the call,
regarding
its lifecycle.
You can find such method somewhere inside Qt (sorry, I don't remember the
class
name but I am pretty sure it has).
The issue here is Qt metaobject system doesn't offer any callbacks on the
events
of importing/exporting a child. A message bus between Qt and bindings.
There is QObjectCleanupHandler, not very helpful in this paticular case.
Things go more complex if we start talking about non-meta classes (which is
declared without Q_OBJECT macro). This side is completely out of control
from
Qt metaobject system.
>
>> 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?
Trust me, I am really not arguing current kde-bindings' implementation ;-)
Please don't treat me like an enermy ;D
I pay my enough respect to you guys behind this maillist, indeed.
Noticed that recently there was a post saying different words on
kdeveloper.org.
I think the author was quite friendly and really wanted to bring new ideas
in.
Things are always improved by questions and innovations.
We can keep walking on each own way but we can share our thoughts, right ?
>
>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?
Sorry, that topic triggered me yesterday.
>
>-- Richard

-- 
cheers,
-dongxu
__END__
http://search.cpan.org/~dongxu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20070719/71786281/attachment.html>