Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-26 22:01:55
Rob, Thank you for your review. It's much appreciated. I feel that your
review echoes the feelings of many other reviewers who mercifully voted
"yes conditionally" which in reality can only be viewed as "yes" to the
desire/idea to have such a library but "no" to this particular
approach/design under consideration. And that's fine by me. Maybe,
indeed, conversion is far too contentious an issue to see a considerable
number of people prepared to compromise. Or, maybe, it might just be
that the review format is flawed where every reviewer comes with his own
(potentially contradicting or not implementable) conditions/ideas but it
is the author's responsibility alone to walk the walk... and maybe even
defend somebody else's designs against later criticism. :-) Regardless
it was fun even if somewhat exhausting trying to answer every "why and
why-not" thrown at you. :-)
Thanks, Rob. Thank you everyone.
On 05/27/2014 10:30 AM, Rob Stewart wrote:
> On May 13, 2014 6:00:46 PM EDT, Edward Diener <eldiener_at_[hidden]> wrote:
>> Please try to sum up your review by answering these questions:
>> What is your evaluation of the design?
> I like the idea of a consistent interface. I don't think we've quite found it yet, but we're close.
> Vladimir has removed "from", but I think using just "convert" is a problem. Switching to "to" or "as" will solve that problem and reduce typing.
> I like that he has provided no-throw, throwing, and default forms. All are important. The simple cases must be easy to invoke, but what's simple and common for one isn't necessarily so for another. Using optional is not unreasonable, but carries the risk of unwanted overhead, which must be benchmarked. Overloads are likely a better choice, and passing something like an error_code is a great option.
> I don't like the approach used for avoiding dependence on a default constructor. Simply passing an instance into which the result is written would suffice and isn't "hidden". It also won't run afoul of the ODR.
> I don't like the requirement to always pass a converter, though doing otherwise introduces various limitations or issues. Thus, overloads are again needed, though I may be asking for far too many overloads by now!
> This puts me firmly in the I-like-the-idea-but-not-the-present-version camp. I'll refrain from listing my preferred syntax since it will only cloud things just now.
>> What is your evaluation of the implementation?
> Not relevant since the interface is much too much on flux yet.
>> What is your evaluation of the documentation?
> A decent start, but needs quite a bit of work. I find it to chatty, for one thing.
> The first page is a nice introduction that motivates the rationale and explains the potential well.
>> What is your evaluation of the potential usefulness of the library?
> I favor a common interface for common things, but I'm not convinced this one interface is useful for anything more than string-to-number, number-to-string, and perhaps, string-to-string conversions. Having said that, I recall my creating a library to manage conversions among a plethora of time types used in our various libraries and operating systems, which was not unlike Vladimir's idea. So, I there may be more use cases after all.
>> Did you try to use the library?
>> How much effort did you put into your evaluation?
>> Are you knowledgeable about the problem domain?
>> And finally:
>> Do you think the library should be accepted as a Boost library?
> Sadly, no. I favor the idea, and I particularly like Vladimir's cooperative attitude so I think something well yet come of this effort, but it's not yet ready.
>> As always whether you do or do not feel that the library should be
>> accepted into Boost please specify any changes you would like to see
>> the library to be better in your estimation.
> I'll try to participate in the ongoing discussions to do that.
> (Sent from my portable computation engine)
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk