[locale] Formal review of Boost.Locale library -- final days
The final day of the Boost.Locale formal review is tomorrow, April 22nd. If you're planning to submit a review but haven't, now is the time. I'll accept reviews up until I complete the report on Saturday morning. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Chad Nelson Oak Circle Software, Inc. * * *
Hi, 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 problems? No. - 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. Best, Vicente
On Apr 22, 2011, at 2:00 AM, Vicente BOTET <vicente.botet@wanadoo.fr> wrote:
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.
...
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.
+1 Sorry, no review this time, just an opinion from following discussion and reading the rationale. Looks like a useful library but I think it could take another revision. Again, apologies for no real review. & thanks to Artyom and Chad.
On Fri, Apr 22, 2011 at 9:42 AM, Gordon Woodhull <gordon@woodhull.com> wrote:
Does this mean that you prefer to have no locale library instead of this one in Boost? Artyom likes his design better (as I understand it). He's probably not the one to write the library you want. Boost accepts different libraries solving the same problem. Isn't this library good enough to be such alternative? Especially since there is no other alternative at all for the moment (or in the foreseeable future). It's not that the library is a sloppy work, as I see it. You just have different expectations. /$
On 22.04.2011 12:07, Henrik Sundberg wrote:
all software aspects affect on the code quality and design is in the first place. A Boost's library must have *excellent* quality but this one isn't even good enough (IMO) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On Apr 22, 2011, at 4:07 AM, Henrik Sundberg <storangen@gmail.com> wrote:
No, I mean I would like to see Artyom try to address some of the design concerns and try again. But I'm not voting, only having an intellectual interest and zero experience with i18n. This is called "standing aside".
Artyom likes his design better (as I understand it). He's probably not the one to write the library you want.
Almost everyone likes their own design better, but the best authors are willing to consider new ideas. Artyom seems to have a good attitude about the smaller issues and I hope he'll think about the big picture too, whether or not the library's accepted.
Boost accepts different libraries solving the same problem. Isn't this library good enough to be such alternative?
I sympathize with what you're saying, but I think it's worthwhile to put libraries through multiple reviews if there's a chance of getting a much better designed library in the process. Cf. Xint, Process. This seems very much in the C++ tradition to me. Cheers Gordon
The OO design is central part of Boost.Locale, there are way-many reasons behind - mostly too keep as much freedom as possible in implementation of local culture requirements. This isn't going to be changed in future revisions. I would likely add some streaming interface where it is needed, I can reasonably improve some other interfaces but this would not be "generic" programming library as it can't be. It is not because I don't like templates or I don't see some things. It just does not fit this library needs and patterns. So this would not be changed. Boost.Locale is object oriented library and will remain so whether it will be part of boost or it will be release as independent library outside boost's namespace.
I do consider valuable inputs I had received and many of them will be included. However the big picture will not change because. If somebody thinks that it is possible to implement useful localization library using non-OOP design, he is welcome to write his own. Then after learning the localization topics, libraries and APIs much deeper he would likely see the bigger picture and understand the rationale behind the design decisions I had done. It may be not obvious for some, but not everything in C++ should be done via generic programming. (BTW I really can't believe that I hear that something is too object oriented...)
It really depends on what reviewers ask. If I think that the request wouldn't do any good to the library it would be rejected with proper rationale. Best Regards, Artyom
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.
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.
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.
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
participants (6)
-
Artyom -
Chad Nelson -
Gordon Woodhull -
Henrik Sundberg -
Max Sobolev -
Vicente BOTET