Servicetype inheritance (Re: kdenonbeta/kopete/libkopete)

[Martijn Klingens]

On Tuesday 22 April 2003 19:31, David Faure wrote:
> Say you have a type of service A (e.g. KParts/ReadOnlyPart)
> and a more specialized type of service B (e.g. KParts/ReadWritePart).
> B inherits from A, which is the usual notion of specialization.

Yup, this is also how Kopete does it (Kopete/Protocol inherits Kopete/Plugin), 
and I did it like this after your explanation at FOSDEM ;-)

> Here's the new reasoning (after my discussion with coolo, and this is
> what led to the recent change in CVS):
> => No, it doesn't necessarily support a "more generic" type of service,
> it can only do the more specialized one.

Hmm, to me that sounds like "the service doesn't inherit the base class" and 
the X-KDE-Derived line shouldn't be in the service type's .desktop file...

> And when asking the opposite question: "if a service T says it
> implements A, does it implement B as well?", the answers are opposite
> ("certainly not" we would say for a ReadWritePart,
> but "yes" if we consider that B is only a special case of A).
>
> In coolo's case, a "samba workgroup" is a special kind of directory.
> So when the iconview says it can display directories, it means it can
> also display more specific directories, such as the samba workgroups.

But why does this need changed inheritance semantics?

I mean, if you have the KDE mime types Dir and Samba (Samba inheriting Dir) 
and the KPart KFileIV that implements the mime type Dir, then if you actually 
get a Samba mime type, shouldn't the trader try to find a handler for Samba's 
base class (Dir) if there's no handler for the Samba type?

Maybe I'm missing something here, but the more I think about this the more I 
fail to see why this is needed in the first place :(

Could you try to explain it a bit more?

-- 
Martijn