Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-05-16 19:03:22
alex <alexhighviz <at> hotmail.com> writes:
>> Vladimir Batov writes
> alex <alexhighviz <at> hotmail.com> writes:
Thank you for your email, continuous involvement and suggestions. It's much
appreciated. I took the liberty re-arranging our conversation... mostly for
selfish reasons ;-) -- 1) the inlined replies were getting difficult to
follow and 2) later it'll be easier for me to address a "bulleted" (as
below) TODO list. Apologies if I managed to miss any of your points.
RE#1: I vote for inclusion in Boost, but would strongly recommend that the
library simplifies the interface AND / OR develops a concept of Converter
that is rich enough to include the advanced functionality of the
REPLY: Thank you for voting for inclusion and for stating that you find the
library useful (at least potentially). It's much appreciated. I
whole-heartedly agree that we neeed a rich and advanced stringstream_based
converter. In practice that happens to be my main converter as well
(conversion performance is not a priority for me). Extending this particular
converter is close to the top on my TODO list (the usual caveat: if the
review successful). However, I'll need to gather user input/requirements
what is the preferred interface, etc. Namely, I was leaning away from using
the std manipulators (and was providing an alternative api) but you found it
useful. So, now I feel we should be providing both interfaces.
TODO: Provide "rich and advanced" stringstream_based converter.
RE#2: Basic things that I would expect from a *generic* converter are not
offered by the Convert library.
REPLY-PART#1: Clearly there is no code that would satisfy every user's need.
Far from it. *Currently* we are at the "consideration/evaluation" stage to
see if that is the correct/valid/promising/sustainable *path* to go ahead
and to implement all those bells and whistles.
REPLY-PART#2: Well, the thing is -- there is no *generic* converter. More
so, in my view there is no even Convert "library". :-) I see my proposal as
a conversion/transformation *framework*. The difference between a library
and a framework (in my view and in this particular case, anyway) is that the
latter is merely the guidelines how to be able to develop code *later* that
is to be deployed in and without disrupting the old/existing code. That's
what convert::from API facade does. On its own it provides very little (if
any) functionality. Its (sole?) purpose is to advertize and to force a
*contract* between the user (service consumer) and the converter developer
(service provider). That allows the user to write his domain-specific code
*now* and to plug some converter later (when it becomes available) or to
replace one converter with another (if/when the requirements change) without
major disruption of the existing code-base.
As you correctly pointed out one-particular-converter functionality can be
called directly rather than via "meaningless" convert::from. The existence
of Convert API facade is more for the purposes of *managing* a large
development which includes *simultaneously* writing components which are
meant to interact or rely on each other; adjusting to requirement changes
without major existing code disruption (that includes major re-writes, major
re-testing, etc.). That's why to this point I am not exactly sure if such an
"administrative" proposal really belongs in Boost where it is overwhelmngly
about clever code.
RE#3: too much lexical_cast-related paranoia and too many lexical_cast
references in the "convert" documentation.
TODO: Focus documentation of "convert", create a separate
RE#4: The following is not compiling because of the way it uses enable_if in
std::string str = boost::convert<std::string >::from("hello", cnv).value();
JUSTIFICATION: It's not compiling because applying std::stringstream to such
a trivial type transformation is wasteful.
TODO: Add "char const*->std::string" transformation specialization to
RE#5: I also think that for a concept this basic, the implementation should
not pose unnecessary restrictions; The convert<>::from function can only
convert to default-constructable types, which I think is not necessary for a
REPLY: The statement above is incorrect. The default-constructible
requirement was actually the main reason I was forced to stop using
lexical_cast and to develop "convert". Please read "The Default
Constructible Type Requirement" chapter.
RE#6: My feeling is that you didn't clarify the concept of a converter
except that it is a function where something goes in and something goes out.
So you might have just as well have called it "algorithm" or "function".
ANSWER: In the documentation it is called "callable". I am sure it is a
fairly standard name, isn't it?
TODO: Extend/elaborate the "Converters" chapter. It purpose/requirements.
RE#7: Did you mean:
>template<class type_in, class type_out, class cnv>
>do_something(type_in in, type_out out)
> convert<type_out>::from<type_in>(in, cnv);
template<class type_in, class type_out, class converter>
void do_something(type_in in, converter cnv)
type_out out = convert<type_out>::from<type_in>(in, cnv);
REPLY: It was merely an example where one might need a generic interface to
be able to plug in some functionality later. A converter can be passed in as
in your example... or as a template parameter:
type_out value_out = do_something<type_in, type_out, converter>(value_in)
Clearly my chosen order of template-type arguments can be improved to allow
for type deduction.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk