[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] more design discussions (an also,KMMF bugs)
From:       ",,," <kde3 () andres ! mail ! kde ! org>
Date:       2002-05-12 1:25:58
[Download RAW message or body]

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 
open for extension". that way, you don't force plugins to extend your 
classes, but you do provide the necessary mecanisms to do so. subclassing is 
a good way of extending :-).
subclassing isn't necesarily heavyweight. for example, KopeteMessage and it's 
subclasses wouldn't even need a virtual table.

now, it's not a one-size-fits-all solution, there might be better ones for the 
problem at hand. the KMPluginData is not as nice as it could be though, 
because of the dynamic_casts.
this outlines a general problem: if we don't subclass, whenever a plugin wants 
to add some kind of customization, and goes through some parts of the 
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 seen 
any working solution currently, and one is needed for 0.4. will you implement 
it ? :-)

cheers,

-- 
Andres
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]