From kopete-devel  Sun May 12 01:25:58 2002
From: ",,," <kde3 () andres ! mail ! kde ! org>
Date: Sun, 12 May 2002 01:25:58 +0000
To: kopete-devel
Subject: Re: [Kopete-devel] more design discussions (an also,KMMF bugs)
X-MARC-Message: https://marc.info/?l=kopete-devel&m=102116665009915

On Sunday 12 May 2002 01:29, Martijn Klingens wrote:

> Well, you're thinking in completely the opposite direction than I... I =
want
> to keep as much code as possible outside the plugin and you want to
> subclass about everything in libkopete into the plugin...

the best strategy is usually "provide what you can in the lib, and leave =
it=20
open for extension". that way, you don't force plugins to extend your=20
classes, but you do provide the necessary mecanisms to do so. subclassing=
 is=20
a good way of extending :-).
subclassing isn't necesarily heavyweight. for example, KopeteMessage and =
it's=20
subclasses wouldn't even need a virtual table.

now, it's not a one-size-fits-all solution, there might be better ones fo=
r the=20
problem at hand. the KMPluginData is not as nice as it could be though,=20
because of the dynamic_casts.
this outlines a general problem: if we don't subclass, whenever a plugin =
wants=20
to add some kind of customization, and goes through some parts of the=20
framework, and then back to the plugin, it's gonna need to dynamic_cast.

we can live with it for now, for the good of 0.4 release. but i haven't s=
een=20
any working solution currently, and one is needed for 0.4. will you imple=
ment=20
it ? :-)

cheers,

--=20
Andres
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel