Re: [boost] Boost review of the Convert library is ongoing

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:

...

Alex,

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. 

Vladimir.

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
stringstream_based converter.

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
lexical_cast-comparison-related chapter.

RE#4: The following is not compiling because of the way it uses enable_if in
sstream.hpp.

  boost::cstringstream_converter   cnv; 
  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
sstream-based converter.

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
*generic* converter.  

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.