[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