Michael Caisse <boost <at> objectmodelingdesigns.com> writes:
I don't have an opinion on this library yet but hope to find time for a review of it.
Please do. As IMHO if the situation does not improve, the library should not be considered for inclusion regardless how this current discussion progresses given how little interest the library generates (which is starkly different from the time the library was written/submitted).
In the meantime, I thought I would comment on this statement. Variations came up in both the bigint and locale reviews. As I'm sure you know, Boost isn't just a collection of libraries. It strives to be a collection of "expertly designed" libraries. I don't remember "it is useful for some users" as being on the list of reasons to accept a library into Boost. Plenty of perfectly usable libraries have been rejected over the years simply because it could be better. I don't recall "giving everyone nothing" as an argument in the past but it sure has become popular recently.
I certainly do see your point and somewhat agree with that. On the other hand, I favor pragmatism, actual results and gradual improvements over idealism and idle pondering. That "expertly designed" approach can be viewed in the right constructive context or instead viewed as elitist and can be too easily abused. The outcome -- workable, usable, immediately useful but not immediately perfect (which is relative anyway) libs are rejected at the whim of someone who may not even need/use that library in the first place. Who wins here? Not the users anyway. I do indeed appreciate the quality of Boost libs. However, I've never used Boost libs out of admiration of their "expert design". I used them because they were/are useful to me. Consequently, I will take something over nothing any day. Even more so with regard to convert/lexical_cast as those talks of "improving"/extending lexical_cast on this list date back at least to 2005. Participants and maintainers come and go. Talks, lexical_cast and the original lexical_cast design stay. And in IMHO the author is perfectly entitled to his view and to his vision. The author's put his name on a certain design and kindly offered it to others. Some people might disagree with the design and might like to do it differently. Fine. Go and do it outside lexical_cast. And that's what has been collectively decided before 'convert' started. I do not believe it is appropriate to approach it with the attitude -- "Yes, you, balding old man, thank you for all your efforts but now we'll take over and take it to the next level". As for "it is useful for some users", then I do not see anything wrong with that. In fact, isn't it *always* the case? No library will be useful for every user.
In this same thread that you responded to a few weeks back the current maintainer stated he no longer has time and is happy if someone else can pick it up: ...
Yes, I am aware of that. That situation has not dramatically changed from two years back when it was decided to proceed with 'convert' -- the author was not actively maintaining the library and then maintainer Alexander Nasonov was improving *underlying* implementation. Despite many suggestions extending interface had never been on the cards. What's changed? Unless now people are bold enough to say -- we'll take what you've done, we'll keep your name and from now on we'll do as *we* see fit. Not nice.
... if the library has no maintainer and the community decides that the best approach would be expanding lexical_cast to support these added features, then it will happen.
I wonder how you identify the "community". Is it those few who happen to be currently on the list vocal on the topic? Surely the original author is part of that community and on many occasions he expressed his view. What do we do with "inconvenient" views? Again, that topic of extending lexical_cast had place and resulted in submitting 'convert'. That was not even my idea. I was hoping Alexander Nasonov would do it all for me ;-) withing lexical_cast. Re-hashing all again that *after* the fact (the implementation based on our decision back then and subsequent submission) is exhausting. And, again, the provided by convert functionality/flexibility are not achievable within lexical_cast single-function interface. Are there any participants of those old convert/lexical_cast discussions still on the list to chime in? Best, V.