[PyKDE] convertSubClass() -- I introduced a bug :-(

[dacut at neolinear.com]

Phil Thompson write:
> On Wednesday 07 April 2004 9:29 pm, Dave Cuthbert wrote:
>> Now, the real bug is if class A defines a subclass converter, no other
>> class derived from A can also define a subclass converter (and expect it
>> to be called consistently).  A's subclass converter has to be aware of
>> the entire hierarchy.
>
> Can you explain more? Each converter handles a non-overlapping part of the
> class tree. They are just called until one of them recognises the object as
> something it knows the specific type of.

Right -- the problem is when the converters *don't* handle a non-overlapping
part of the tree.  This doesn't happen in the stock PyQt.

The reason this has (sort of) happened to us is that we've extended the
(non-QObject-derived) QCanvasItem classes in C++.  QCanvasItem's subclass
converter, however, only knows about the types defined by Qt directly.

If subclass converters were allowed to overlap, we could define our own
converter without modifying the PyQt source directly.  This procedure would
also introduce probably unacceptable overhead.

Our solution was to treat QCanvasItem as a special case (which it is). 
Instead of hard coding the integer RTTI id's as in the switch statement, we
provided a registration function which allows us to map the RTTI id to
sipWrapperType objects.

This whole situation is what got us into trouble with the other errant patch
we suggested.  We misunderstood your code yet managed to "confirm" our
misunderstanding by "fixing" it and getting the results we expected. 
Occam's razor shaved a little too close this time. :-)

Dave