Re: [boost] [locale] Formal review of Boost.Locale library -- final days

Subject: Re: [boost] [locale] Formal review of Boost.Locale library -- final days
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-22 05:06:15

> From: Vicente BOTET <vicente.botet_at_[hidden]>
> 
> I don't want to see yet another date-time library
> in Boost hidden  inside a library as local, if we
> need a better Date-Time library either the  current
> one needs to be updated or a new one must be proposed
> as a standalone  library ensuring that it is better
> than the current one. See my other posts. 
> 

There are two problems with this statement:

a) Date-Time by its nature is locale dependent, so it
   should be part of localization system and in fact
   it is in other libraries like Qt.

   There is a current very good date time library that
   is suitable for handling Gregorian calendar
   but it is not sufficient for Localization
   where the calendar can be non-Gregorian.

   Also I don't see anybody who would ever
   implement for boost dozen of different calendars
   supported by Boost.Locale via ICU.

   And for the record in my country - Israel 

   I agree that Timezone handing in Boost.DateTime
   should be improved but this is in TODO list
   for years and hadn't moved to far since then.

b) I don't see a problem with alternative library
   for Date-Time handling as there are Boost.Lambda
   and Boost.Pheonix and there are several parsing
   libraries.

   I don't think there is a problem with it.

> 
> - What is your evaluation of the design?
> 
> I don't like the OO  design. I think that a more
> generic approach could be applied to this domain,
> and add a dynamic approach in top of the static one.
> 

I can say one thing, when it comes to localization,
you should do as few assumptions as possible, for example
current std::num_put and std::numpunct does too many
assumptions about the way numbers look like
not allowing to do full range localization.

So as more dynamic approach is used there is a better
chance that it would support the culture you
do not know.


> Even if the library  is presented as a
> C++ wrapper to some useful libraries,
> the interface is not  enough independent
> from them (See my post on gettext interface).
> The  interface must be independent of the back 
> end and more in line with the modern  C++ ≈facilities.
> 

The interface is quite standard and similar for
all localization libraries around.

> The DateTime part is not at the level I would expect and  needs to be extracted 
>and improved.
> 

See notes above.

> And finally, every review should answer this question:
> 
> - Do  you think the library should be accepted as a Boost library? 
> 
> I don't  think the library should be accepted as it is now.
> The library should be  redesigned with a generic approach

This would not happen, it is the current design and it suits
localization needs.

It would not be "template" library.

> and the interfaces be more user friendly and  safe.

You hadn't mentioned (apart of gettext) where interfaces
are not friendly or save.

Mode details would allow be to answer or improve 
them if the requests are reasonable.

> Best,
> Vicente

Thank you for the review.

Artyom