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
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
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
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.
Thank you for the review.