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

[dacut at neolinear.com]

Phil Thompson wrote:
> Why would overlapping converters (ie. the same class is handled in more than
> one converter) ever be required?

It shouldn't... but the problem (can) manifest itself due to is-a
relationships.

As an example, let's say that base class A has subclasses B, C, and D.  The
SIP subclass converter for A knows how to downcast to B, C, and D.

Now I create class E, a subclass of B.  Because any E instance is also a B
instance, the subclass converter for A would downcast this to B -- Python
would not have any of E's features available.

AFAICT, this problem does not manifest itself in Qt or PyQt -- QObjects have
their own metaclass information, and QCanvasItem's subclass converter will
return NULL for unknown subclasses.  I don't have the source right now,
though, so I'll have to double-check.

This aliasing would happen, though, for any converter which relies on
dynamic_cast<>() (and some other kits which have their own RTTI).

> You *can* provide your own converter that handles only the new classes you
> have defined. SIP will try *all* convertors based on the same base class
> until one successfully recognises the instance as being of a class that it
> handles.

Actually, in our case it was colliding with the builtin Qt classes and
returning a QCanvasPolygonItem (or somesuch -- I'd have to check with Greg).
 But that was probably due to a bug in our code (I'm don't know if he knew
of the rtti() virtual method of QCanvasItem; I didn't, either, until a few
days ago).

So, anyway, we came up with a lot of solutions for things that are probably
going to end up being non-problems.  C'est la vie. :-)

Dave