>On Wednesday 18 July 2007, Dongxu Ma wrote:<br>>> Hello Richard, CC: gents,<br>>><br>>> Beside object bus, how do you deal with allocation of Qt/Kde object ?<br>>> First I'd like to share you my progress on my QT4 Perl binding. Due to
<br>>> personal issues, I recently didn't pay much time on coding...<br>>> The typemap system is almost finished. You can check here (<br>>> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl" target="_blank">
http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl</a>)<br>>> The typemap, as you know in perl, is the repos for type marshalling between<br>>> perl and c++ plants. While the old typemap mechanism introduced by
<br>>> ExtUtil.pm is somewhat out of date, it has no knowledge about relationship<br>>> between relevant types. Say, for instance, QString and QString *. Typemap<br>>> simply treats them as un-relevant ones.
<br>>> What I did in tha script is a knowledge study and relationship analyse<br>>> system. For above example, in case it knows QString is a QObject (obviously<br>>> from qstring.h), it automatically knows how to marshall QString *, QString
<br>>> &, const QString, const QString * and QString const *. Furtherly<br>>> QList<QString *> is possible. It goes thru different aspects to find type<br>>> relationship ( class declaration, inheritance tree, namespace path,
<br>>> pre-defined typemaps ).<br>>> It is powerful enough to bridge native Qt type with KDE type, custom type.<br>>Well I think we already have this sort of thing in the Smoke libs, and we have<br>>a parser written in perl with powerful abstract syntax tree utilities for
<br>>walking round the parse tree.<br>Nice. I used to have a look at Smoke, the output is quite programmatic look (in C),<br>that is one of the primary reasons I'd like to write QTEDI, which presents in more <br>human-readable style. While that doesn't mean Smoke is ugly, really depends on 
<br>how people make use of.<br>><br>>> While the bad situation I am facing is GC system. Perl uses simple<br>>> reference, while ruby makes use of mark and sleep way. On the another hand,<br>>> generally, various cases may mess GC:
<br>>> 1) GC in Qt itself: Qt maintains its internal object reference status;<br>>> 2) non-new method which exports an internal address,which will have the<br>>> same lifecycle of exporter;<br>>> 3) non-new method which returns a new heap address, which transfers the
<br>>> ownership of that pointer to caller;<br>>> 4) non-new method which accepts a pointer and takes the ownership of that<br>>> pointer;<br>>><br>>> Either case will leak the vm unless treating it carefully.
<br>>> I'd like to hear your words on this question.<br>>The Smoke bindings have a struct like this:<br>><br>>struct smokeqyoto_object {<br>>   bool allocated;<br>>    Smoke *smoke;<br> >   int classId;
<br> >   void *ptr;<br>>};<br>><br>>Where 'allocated' is true if the instance was created in the bindings<br>>language, and so the bindings runtime is responsible for deleting the C++<br>>instance on garbage collection.
<br>><br>>The bindings runtime needs to know about the various rules of object ownership<br>>in the Qt libraries such as the QObject object tree where a parent 'owns' its<br>>children and is responsible for deleting them.
<br>><br>>The QtJambi bindings have a third state, which is 'not owned by either c++ or<br>>the bindings language'.<br>The hard point here is the handover of object relationship is really case by case. <br>
The metaobject system in Qt is mainly based on class inheritance hierarchy. <br>That doesn't really work for the case: the instance exports an inner part (note <br>that such part is in-a-class, not is-a-class); while other method may export a 
<br>component of itself, which is certainly a standard QObject, and release the <br>ownership of that component to caller; From my point of view, it is very hard to <br>tell such two different cases automatically.<br>Another example to address one of my previous points: say, one creates a new 
<br>QObject in binding code, then QObject is owned by binding code till a special  <br>method is invoked, which takes that QObject as parameter and finally 'eats' it. <br>That dedicated QObject is taken over by Qt metaobject after the call, regarding 
<br>its lifecycle.<br>You can find such method somewhere inside Qt (sorry, I don't remember the class <br>name but I am pretty sure it has).<br>The issue here is Qt metaobject system doesn't offer any callbacks on the events 
<br>of importing/exporting a child. A message bus between Qt and bindings. <br>There is QObjectCleanupHandler, not very helpful in this paticular case. <br>Things go more complex if we start talking about non-meta classes (which is 
<br>declared without Q_OBJECT macro). This side is completely out of control from <br>Qt metaobject system. <br>><br>>> PS: boost python binding page also discussed similar issues. Go and take a<br>>> look.
<br>>What will it tell us that we don't already know, and what do you think is<br>>wrong with out existing approaches?<br>Trust me, I am really not arguing current kde-bindings' implementation ;-) <br>Please don't treat me like an enermy ;D
<br>I pay my enough respect to you guys behind this maillist, indeed. <br>Noticed that recently there was a post saying different words on <a href="http://kdeveloper.org">kdeveloper.org</a>. <br>I think the author was quite friendly and really wanted to bring new ideas in. 
<br>Things are always improved by questions and innovations. <br>We can keep walking on each own way but we can share our thoughts, right ?<br>><br>>Note that the subject of this thread is 'splitting up the smoke libraries' -
<br>>please can you start a new thread to discuss anything which isn't about that<br>>topic?<br>Sorry, that topic triggered me yesterday. <br>><br>>-- Richard<br clear="all"><br>-- <br>cheers,<br>-dongxu<br>
__END__<br><a href="http://search.cpan.org/~dongxu">http://search.cpan.org/~dongxu</a>