alex
Vladimir Batov writes alex
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
template
do_something(type_in in, type_out out) { ... convert ::from (in, cnv); }
template