[Development] QLocale work

[lars.knoll at nokia.com]

On 1/18/12 1:40 AM, "ext John Layt" <jlayt at kde.org> wrote:

>On Monday 16 Jan 2012 23:13:39 Thiago Macieira wrote:
>
>> I'd say that QLocale should return the information you need. If you
>>need to
>> display that, why shouldn't QLocale provide that info?
>> 
>> *Setting* the info is, however, out-of-scope for Qt.
>
>When I was discussing it with Denis at QtCS he was fairly clear he didn't
>want 
>to clutter up the QLocale api with lots of getX/getY/getZ api (he didn't
>like 
>what was already there), but was happy for it to be in another class
>embedded 
>in QLocale, which is why I've mentioned in the past a QLocaleSettings
>class, 
>or doing something more with QSystemLocale to make it return all settings
>not 
>just a limited subset of host settings.
>
>In fact, QSystemLocale is on my hit list, as both the implementation and
>its 
>API seem to me ugly and awkward and a potential BIC problem.  Currently
>the 
>public base class has 2 virtual methods defined on it with no base
>implementation in the main file and no private d class.  The main virtual
>query() method takes an enum and optional QVariant for the required
>setting 
>and returns a QVariant holding the setting.  Each host system file then
>implements the two virtual methods at base class level, i.e. not actually
>derived or virtual, but usually using a private d class or structure for
>the 
>actual implementation.  In the future as we add more features using CLDR,
>there's no guarantee the current API will stretch to fit and the virtual
>methods would normally make it fragile if they were actually being used
>that 
>way.
>
>What I would prefer is to make the public QSystemLocale class a default
>implementation with non-virtual methods and a private d class that is
>virtual 
>and has derived implementations for each platform.  This seems safer and
>cleaner, and would also allow us to add a nicer more direct API, e.g.
>decimalPoint() instead of query(DecimalPoint).  This base class then
>looks 
>just like what a QLocaleSettings class should be, if the base d class
>were to 
>return the CLDR settings.  A system QLocale instance would have a pointer
>to 
>the static global QSystemLocale instance to use, but a named QLocale
>instance 
>would create it's own QSystemLocale without the system overrides.  The
>QLocale 
>parse/format methods would then just have a single code path querying the
>settings and passing them to ICU to use.
>
>That's one possible model anyway, there's still some thinking required on
>the 
>finer details.

I'd say we should make QSystemLocale private for now. There's few reasons
for it to be public and it might lead to BC problems further down the
road. If it's private, we at least have full freedom to evolve the code
base as needed.

Cheers,
Lars