On Thursday 01 October 2009 09:06:21 pm Marcelo Lira wrote: > 2009/10/1 Richard Dale <[email protected]>: > > On Thursday 01 October 2009 06:46:35 pm Renato Araujo Oliveira Filho wrote: > >> Hi Richard, > >> > >> I agree with almost everything you write. I will try clarify some > >> points of our decisions. > >> > >> On Thu, Oct 1, 2009 at 8:53 AM, Richard Dale <[email protected]> wrote: > >> > Thanks to the release of PySide last month I have put a lot of thought > >> > into Python bindings, started a QtScript bindings project, and have > >> > even become something of a Python fan! I thought I'd write a brain > >> > dump of my thoughts on using the Smoke libraries for a Python binding. > >> > > >> > Smoke was originally designed by Ashley Winters and the PerlQt team in > >> > 2002. Since then it has been used for QtRuby, Qyoto C#, PHP, Common > >> > Lisp and PerlQt4 bindings. The idea is very simple and I would call it > >> > a 'moc on steriods' as it works just like slots and signals are > >> > implemented in Qt, but for the entire library rather than only some > >> > methods, and has features like virtual method override callback > >> > handling, and caters for multiple inheritance, which the moc lacks. > >> > >> We know a little about smoke, in the past we took a look in ruby and > >> Qyoto bindings, they have different use of smoke, and both are a good > >> examples of use smoke. But our first concern about smoke is the > >> performance. We can continue discuss about this. And I would like to > >> see how smoke handle with caters for multiple inheritance, because > >> this is a big problem for us. > > > > It is quite possible that the performance of Smoke won't fit your needs, > > or maybe it will, or maybe it will if we do some tuning. What I would > > like to do is to get enough projects using Smoke that we can afford to > > spend the time tuning it, instead of just trying to get it working in the > > first place. > > > > Multiple inheritance 'just works'. If you want to obtain the parent > > classes of a class you can. All the virtual methods of multiple > > superclasses can be overriden. > > > > With QtRuby I don't attempt to model the C++ class heirarchy, and all the > > classes are on a flat level, just inheriting from Qt::Base (Ruby doesn't > > have multiple inheritance). Then I have overriden the Ruby introspection > > methods to make it look like there really is a Ruby class heirarchy. My > > understanding of the Boost::Python bindings was that the classes were > > flat, and that a QWidget was not a subclass of QObject in Python terms. > > But in Python, we can make tp_bases tuple a list of multiple superclasses > > and have the same heirachy as in C++. > > The Python bindings uses multiple inheritance, and Shiboken already > registers the parent classes on tp_bases. > > The problem Renato is referring to is when you cast an instance of a > multiple inheriting > class to void* and then cast back to one or the other of the base > classes the memory > address changes. > > If we have > > class Transformer : public Car, public Robot > > Then we have something like this memory model: > > +------------------+-------------+ > > | 0x80518e8 | 0x80518f0 | > > +------------------+-------------+ > > | Transformer, Car | Robot | > > +------------------+-------------+ > > If we pass the Transformer as a parameter to some wrapped method > that receives a Robot as type, the pointer gets all messed up with > Boost.Python. With the CPython bindings we still didn't touched this > point, but I expect to be less cumbersome to deal with it without being > bounded to the Boost.Python rules (my sort of superficial expectation on > this). > > The summarized question is: does smoke provides any help on this matter? Yes, it has cast methods to cast to all possible parents of a class. If you have a 'void *' and you don't know what actual class it is, then you would be stuck though of course. The first argument is the 'void *' the second the classId of the current class, and the third the classId of the target class:
static void *cast(void *xptr, Smoke::Index from, Smoke::Index to) So it is very similar to the way the moc adds casts in the generated code. In the hash of C++ pointers to their corresponding bindings instances, all possible pointers are stored by going through the parent classes of the instance to be inserted, and using the above cast methods to get the different pointer addresses. -- Richard _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
