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

[Phil Thompson]

On Sunday 11 April 2004 8:34 pm, dacut at neolinear.com wrote:
> 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.

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

> 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.

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.

Phil