KLocale::formatDate()

[Friedrich W. H. Kossebau]

Am Montag, 5. Februar 2007 00:07, schrieb David Faure:
> On Sunday 04 February 2007, Adriaan de Groot wrote:
> > I don't know what it costs to create a spare KLocale object, it just
> > seems very extra-kludgy to me.
>
> (unless you need to do more than one reading/formatting with the given
> format) But indeed there's a lot of initialization in klocale so better
> avoid doing that too many times, I agree. I just don't like the resulting
> API - for consistency and completeness we need to have overloads that pass
> a format to formatNumber, formatMoney, formatLong, formatDate, formatTime,
> formatDateTime(QDateTime) and formatDateTime(KDateTime)? See that's quite a
> lot of api bloat... And generally speaking, it just encourages to hardcode
> formats in the applications.
>
> Just my 2 cents, if there's really much code that needs this then I'm not
> really objecting.

Two more examples I have come across:
* setting an own date string for the clock applet, like DD.MM. (not yet 
implemented)
* looking up the wikipedia page for a year's day needs also a custom formatted 
string (done by a plugin for the Khalkhi framework)

And both wouldn't work to well with hardcoding the custom format, so no fear 
with this.

Friedrich