[Development] QLocale work

[John Layt]

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.

John.