std.locale

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-03-02 08:32:40 -0500, Leandro Lucarella <llucax at gmail.com> said:
> 
>> I'm not following this thread carefully and I don't know if this is what
>> you are implying, but: Please don't you even think in duplicating the
>> locale stuff, at least on unix there is a very nice database that 
>> needs to
>> be updated sometimes very often (due to stupid presidents like the one
>> I have now that changes the summer saving time all the time).
>>
>> PHP for example maintains a copy of this locale data and is a real PITA.
> 
> I do agree.
> 
> In another post I proposed we create formatter classes for numbers and 
> dates. This way, you can use a formatter binding to the UNIX database 
> and APIs, or the Windows APIs, or Cocoa, etc., or you can build your 
> own. All you need is a generic front end formatter interface you can 
> bind to anything (and a common internal representation for dates) 
> something like:
> 
>     interface DateFormatter
>     {
>         string timestampToString(int timestamp);
>         int stringToTimestamp(string date);
>     }
> 
>     DateFormatter defaultDateFormatter();
>     DateFormatter dateFormatterForLocale(string localeName);
> 
>     interface NumberFormatter
>     {
>         string intToString(int number);
>         int stringToInt(string number);
>     }
> 
>     NumberFormatter defaultNumberFormatter();
>     NumberFormatter numberFormatterForLocale(string localeName);
> 

This is exactly one thing I want to avoid for Phobos: defining class 
hierarchies for locales.

No.

If you want to provide a specific date formatter, you plant a delegate 
in the locale table. The code in Phobos doing formatting will detect 
that and call your delegate passing in the date. You do whatever you 
want on your side (format on the spot, use your own class hierarchy etc.)

Again: mechanism only. Not policy.


Andrei