Use of Boost library classes in kdecore?

[David Jarvie]

On Sunday 08 July 2007 00:09:29 Thiago Macieira wrote:
> David Jarvie wrote:
> >Having looked at implementing this, I realise that it won't work. The
> >KTimeZone base class objects provided by the API must be polymorphic,
> > i.e. a KTimeZone object/pointer must act like a pointer to that it can
> > represent any derived class object as well, and call the appropriate
> > virtual functions. Giving KTimeZone a QExplicitlySharedDataPointer
> > d-pointer doesn't provide this, and would still be necessary to use
> > pointers to KTimeZone to achieve polymorphism, which bypasses the
> > ref-counting and is no better than the current implementation.
>
> The alternative is to flatten the hierarchy and remove the need for
> derived classes in application code.
>
> What descendants of KTimeZone exist and why must they be used? Is the
> application author supposed to derive from KTimeZone?

There are two classes in kdelibs: KSystemTimeZone, which represents time zone 
data returned by glibc funtions, and KTzfileTimeZone, which represents the 
full time zone data held in the system time zone database. The former only 
gives information for recent years, but is presumably faster to call than the 
latter, which reads and parses the database files.

But there are other forms of time zone data, notably iCalendar VTIMEZONE data. 
This is represented in kdepimlibs/kcal by the ICalTimeZone class. It contains 
extra data compared to the other classes. There could also be a need in the 
future to cater for other data sources which may have different information. 
By allowing classes to be derived, kdelibs doesn't restrict the data which 
they can access, and of course, it avoids having to change KTimeZone's API 
every time a new time zone data source is implemented.

Application authors would rarely derive from KTimeZone - it's probably more 
likely that derived classes would live in libraries.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm