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

List:       kde-core-devel
Subject:    Re: KLocale::formatDate()
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2007-02-13 13:00:26
Message-ID: 200702131400.26800.kossebau () kde ! org
[Download RAW message or body]

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