Proposed new KDateTime class
David Jarvie
lists at astrojar.org.uk
Wed Nov 16 00:50:04 GMT 2005
On Wednesday 16 Nov 2005 00:41, Tobias Koenig wrote:
> On Tue, Nov 15, 2005 at 01:17:42PM +0000, David Jarvie wrote:
> > On Mon, Nov 14 2005 at 11:06, Tobias Koenig wrote:
>
> Hi David,
>
> > >Yes, they are. In 4.0 we'd like to be able to serialize libkcal objects,
> > >so a serializer for a datetime class is a must.
> >
> > That would require a serialiser for the KTimezone class (which is one of
> > the private components of KDateTime). KTimezone is polymorphic, so you
> > couldn't have operator>>(QDataStream&, KTimezone&)
> > because the memory size required by the KTimezone object would be
> > unknown.
>
> The class KTimezone could offer a method
> KTimezone::toStream( QDataStream &stream );
> and
> KTimezone::fromStream( const QDataStream &stream );
> which are reimplemented by the subclasses.
>
> In operator>>( QDataStream &stream, KDateTime &dateTime ) you would call
> dateTime->mTimezone->fromStream( stream );
Yes, that would work, except for the problem mentioned below...
> > instead, with the serialisation method constructing a new KTimezone of
> > the appropriate class, and returning a pointer to it. The problem then
> > would be how operator>>() would be able to determine which KTimezone
> > sub-class was contained in the QDataStream, given that it doesn't know
> > what classes may in the future be derived from it.
>
> We can use enums for the subclasses. Isn't there a limited number of
> possible timezones anyway?
The problem is that anybody could subclass KTimezone. There will be a subclass
for iCalendar time zones (already committed in libkcal), but there could be
subclasses for any new type of time zone source, if it turned out that some
application needed to access it. So we can't say in advance how many
subclasses there will be - we can only know how many there are currently. So
we can't declare an enum in the base class without changing the base class
every time somebody implemented a new subclass. Therein lies the problem.
--
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html
More information about the kde-core-devel
mailing list