Extender api review round 4

[Kevin Ottens]

Le Tuesday 02 September 2008, Rob Scheepmaker a écrit :
> - No virtual initExtenderItem in Applet. [...] Other solution would be a
> signal/slot mechanism. Advantage of this would be that it won't break binary
> compatibility, but that isn't really an issue since I believe it's kind of
> decided that binary compatibility would only be an issue after 4.2.

IIRC I was in fact proposing a signal in Extender, not in applet. That makes a 
difference, see below.

> - No extender() in Applet. [...]

I think I'm mostly the only proponent of those two ones. But I will state it 
again a last time because from the comments I've seen floating around I think 
my motivation for those ones got misunderstood.

My reasons for not having them are the following:

If the Extender class is to follow a decorator-like pattern (at least 
presenting itself like this from an API standpoint), then Applet can't depend 
on Extender. It simply comes from the fact that you're supposed to be able to 
stack up several decorators on a component, such a dependency sort of assume 
a) only one type of decorator and b) a special status of the Extender one.

Then another problem is obviously showing up if we step back a minute and look 
at how the API could evolve from here. It's likely that we'll have more 
options following the decorator pattern for Applet. And then we'd have two 
possibilities (assuming we could break BC):
1) The BIC option, which basically adds two methods to Applet related to this 
new "decorator". Just like we have initExtenderItem() and extender() now. This 
way we'd keep consistency in the API for all our decorators. After some time 
it means cluttering the API with this kind of convenience accessor, not used 
in most cases.
2) The BC option (the one which will happen), which basically forces us to 
implement the new decorator like I propose Extender to be API wise (that is 
signals in the decorator for init purposes and no accessor from the Applet). 
As soon as we'll add one more decorator after Extender the API will then be 
inconsistent. Extender will always be a special case.

In the end, the real question is "how likely" will we have more decorators for 
applets. I tend to stand on the safe side here because the probability is 
definitely not null, hence why I proposed the changes needed to avoid a Applet 
-> Extender dependency in the API.

At first it always looks nice to achieve something completely automatically 
using one line like "new Extender(this)". That looks cool because the 
extenders are the new cool thing in town (yes, they definitely are great 
imho). But, we've to face the fact that not all applets will use them (far 
from it). That's why I prefer that we have to write a few more lines in the 
cases where they're used and make sure the API will stay lean longer.

Thanks for your attention.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080916/5647cdc7/attachment.sig