[PATCH] *UPDATED* API review of KCalendarSystem* and KDate* widgets

John Layt johnlayt at yahoo.com.au
Sun Jul 22 01:45:43 BST 2007


On Saturday 21 Jul 2007, Alex Merry wrote:
> On Saturday 21 Jul 2007, John Layt wrote:
> >   StringFormat { ShortFormat,
> >                  LongFormat, };
> >
> >   MonthNameFormat { ShortName,
> >                     LongName,
> >                     ShortNamePossessive,
> >                     LongNamePossessive, };
> >
> >   WeekDayNameFormat { ShortDayName,
> >                       LongDayName, };
>
> Can you make this consistent?  There's a mix of Format and Name here.
>
> Alex

Well, they are for two different things, so after intitailly wanting just one 
enum, I had to go for two, then three.

The first one is for the methods:
    QString dayString( int, StringFormat )
    QString monthString( int, StringFormat )
    QString yearString( int, StringFormat )
that return a date portion number as a string, e.g 2007 as "2007" or "07", 
Name doesn't really work for that whereas a Format is what it actually is, 
e.g. YYYY versus YY.

The other two are for the methods that return names, not formats:
    QString monthName( int, MonthNameFormat )
    QString weekDayName( int, WeekDayNameFormat )
so Name seemed more appropriate, as a format implies all values adhere to a 
common pattern like YYYY which is not the case.  Something like 
ShortMonthFormat just doesn't read right.

I'm pretty happy with the values themselves and how they read in a line of 
code (except maybe to add month into some e.g. ShortMonthName, but it reads a 
little akward in code).  I'm still a little unsure on the actual enums, 
perhaps MonthNameFormat should be more something like MonthNameStyle to 
emphasise it's not a format.

I'm certainly open to suggestions for better names :-)

John.

--

Send instant messages to your online friends http://au.messenger.yahoo.com 





More information about the kde-core-devel mailing list