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

List:       kde-pim
Subject:    Re: [Kde-pim] About non-gregorian calendar systems
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-02-26 13:47:33
[Download RAW message or body]

On Tuesday 26 February 2002 14:18, Frans de Wet wrote:
>
> If we create a object for each date type that would not in itself help
> much. When programming a user interface it would be much to complicated to
> make use of this easily.  The only way I would really be willing to use
> this would be if the class KDate or CalendarSystem (I like this more)
> encompassed all of this, and provided a single access point for all the
> different date types. The class CalendarSytem or Kdate would have to look
> very much, if not exactly like QDate to be backwards compatible and provide
> a logical upgrade path.  In addition I would want to be able to say
> something to the extent of
>
> aDate.getYear(HELLENIC); //Return the hellenic year
> aDate.getYear(); // Return the Gregorian year (this is the way QDate works)

This would mean that you would have to implement all the conversions in the 
Date class. I don't think that this is a good idea.

> So, if I look at this from a requirement side it makes sense to my warped
> brain that I do not want to have 10 different classes or types of calendars
> to worry about when writing a program, I only want to worry about one.  As
> such I do not want to  have to go from CalendarSystem to HCalendarSystem to
> get a hellenic representation and from CalendarSystem to GCalendarSystem
> tto get the Grogorian representation etc ... I want to only use one class
> which could be CalendarSystem or KDate and it should handle all the
> complexities for me.  I do not want to change my code when a new
> date/calendar system is developed, I just want the new date system to show
> up in a list box somewhere and if the user selects it that is stored as a
> preference.  I will then draw the calendar and convert all the dates to
> what the user selected by just passing the users preference to all the
> functions.

All code uses the abstract CalendarSystem interface. There is only one place, 
where the specifig GreogrianSystem or ChineseSystem is used, when the object 
is instantiated (based on user selection).

> So, if I was to write this I would try to make it as easy as pie from the
> frontend to convert between dates.  This would be accomplished by just
> specifying a type (or not).  This can then be used to convert between date
> formats too ... by loading (or constructing) the date object with a
> specific date type (which is then converted and stored in QDate format) and
> then retriieving it with another type specified.  No casting and the type
> is transparent and not dependent on the code of the final application.

Conversion is not the problem, but to identify, which properties of the 
calendar system affect the display and provide these in an abstract way.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]