[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:       Martijn Klingens <klingens () kde ! org>
Date:       2002-05-12 1:42:42
[Download RAW message or body]

On Sunday 12 May 2002 03:25, ,,, wrote:
                               ^^^^^^^^^^^^^^^^^

Trying to be anonymous? ;-)

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

If you want to support value-based KopeteMessages as opposed to using pointers 
to them you do. After all the operator= should be made virtual if the size of 
the object is unknown. If we use pointers then you're right, although I 
thought we agreed that the ability to allow copying KMs was a big plus.

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

Only one: inside the protocol handling the messageSent signal. KMM doesn't 
need to cast because it doesn't care and the optionsWidget obviously holds a 
pointer to the true (derived) class for its internal bookkeeping anyway. Not 
that complex, a single dynamic_cast for all places where the class is used. 
That's the advantage of our single entry point in KopeteProtocol :-)

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

Sure. But apart from the optionsWidget, or whatever the post-0.4 approach will 
be I don't see that much cases for such roundtrips.

> 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 ? :-)

Uhm... implement *what* ? (Note that I rather try to fix the chats in MSN 
though, that's another showstopper for putting KMM branch out as 0.4.)

Martijn

_______________________________________________
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]