Subject: Re: [boost] [locale] Formal review of Boost.Locale library -- final days
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-04-22 02:00:04
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.
- 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.
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 DateTime part is not at the level I would expect and needs to be extracted and improved.
- What is your evaluation of the implementation?
I've not see it.
- What is your evaluation of the documentation?
I would preferred if the documentation followed the Boost presentation.
- What is your evaluation of the potential usefulness of the library?
I think the I18n part is a must have in Boost, but the proposed interface doesn't satisfy my expectations.
- Did you try to use the library? With what compiler? Did you have any
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
I spent 10 hours reading the documentation and quite a lot of time reading the review threads.
- Are you knowledgeable about the problem domain?
I have needed to do internationalizable applications in the past. But I'm at all an expert in the Localization domain. We used token identifiers while identifing the translation part to overcome any locale issue.
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 and the interfaces be more user friendly and safe. I know the author is against the generic approach so I don't expect he will change later on if the library is accepted. If the library is accepted, I expect at least the DateTime part will be removed.
Please count my vote as 1/2 or 1/4 vote as I have not take the time to make the concrete proposals that will be needed to make this library acceptable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk