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? -- Marcelo Lira dos Santos INdT - Instituto Nokia de Tecnologia _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
