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 _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
