Date/time class changes to handle extended date ranges

R.F. Pels ruurd at
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.


> 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

More information about the kde-core-devel mailing list