[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposed new KDateTime class
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2005-11-16 0:50:04
Message-ID: 200511160050.05016.lists () astrojar ! org ! uk
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic