Date/time class changes to handle extended date ranges
R.F. Pels
ruurd at tiscali.nl
Sun Feb 19 23:25:16 GMT 2006
On Sunday 19 February 2006 21.17, Thiago Macieira wrote:
> I'm sorry, I'm not following.
>
> If there is a KFoo class that extends a QFoo class, it is obvious that it
> extends *something*. If it followed the exact same API and same contract,
> there wouldn't be any need for a new class: you'd just use the QFoo one.
Correct.
> So I fail to see how extending the range is breaking the contract.
> However, when one class extends another, it should properly document what
> it is extending.
There is a reason for calling the act of inheriting from another class
'specialization'. This is what we see in KDE all the time. In fact, as soon
as you learn the Q->K convention, a class named KDialog says directly to us:
"I am a QDialog specialization SPECIFICALLY meant
to be used in the KDE framework."
The contract is NARROWED in this case as it should be.
My point is - and stays - that if you use a classname that IMPLIES derivation
from a corresponding class in Qt in the light of the Q->K convention - even
if that is not the case - you are in fact encouraging confusion. If on top of
that conversion operators are added that are NOT guaranteed to succeed
because the contract of the target class is too narrow the confusion is
complete. This will lead to ugly boilerplate checking code or horrible
constructs like
bool KDate::isConvertibleToQDate() const;
> I don't agree. So there should be no KApplication because it may register
> with DCOP while QApplication does not? Or no KMenuBar because it may show
> at the top of the screen and is styled?
If KDate and KDateTime had been classes with a contract as broad as the class
they derive from but not broader, I do not have a problem with that. The
examples you give - KApplication and KMenuBar - are proper specializations in
that respect along the lines I mentioned above. They are classes meant to be
used in the KDE framework and not in a different Qt-derived framework.
--
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel
mailing list