Re: [boost] [convert] Now with Boost.Parameter interface.

Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-07-01 07:28:36

> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>> >> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = 
>> >> true);
>> >> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>> 1) #2 uses the same interface/notation as ">> std::hex" (I
>> admit of being a consistency/uniformity freak);
>
> I like consistency, too, but as Emerson said, "a foolish consistency
> is the hobgoblin of little minds," so let's not put too much stock in it.

Yes, I've heard that quote. The problem with its applicability here as I see 
it is that 1) we have to define what constitutes a *foolish* consistency; 2) 
in his "Self-Reliance" Emerson's interpretation of consistency was not even 
close to our interpretation of the word within our s/w engineering domain. 
Emerson's interpretation (and dismissal) of consistency is clearer when he 
elaborates further -- "Speak what you think now in hard words, and to-morrow 
speak what to-morrow thinks in hard words again, though it contradict every 
thing you said to-day".

So, I feel that the deployment/interface consistency might not be that 
easily dismissed with Emerson. Still, I do realize that for better or worse 
i/o streams somewhat usurped >> & << operators. That said, I personally do 
not feel it is such a hurdle (to me anyway) and I am guilty of using op>>() 
for manipulators and locales.

> ...
> Combining the need for a using directive with the lack of named 
> parameters,
> I find the use of named parameters questionable.  They add compile time
> overhead and some code complexity for relatively little value.
> I have forgotten now the arguments against the following,
> but I offer it again as a better interface because there's no
> using directive needed, yet there's a distinction between
> influencing the convert framework's behavior and the
> IOStreams conversion operation:
>
>   int i(convert<int>::from(str, 0).locale(new_locale).throw_());

I do not feel (or remember) there might have been arguments against the 
interface above. It is an old and humble alternative to Boost.Parameter - 
another approach to the "Named Parameter Idiom" described in 
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18. Still, I 
personally like Boost.Parameter better as I feel it implements the idiom in 
a generic and more consistent manner. More so, Boost.Parameter-based 
interface is easier to deploy across different conversion specializations. 
That said, it'd be ideal to collect more input from the people using 
boost::convert. I admittedly have not had much (if any) input but still 
hoping that the situation might improve with time and closer to the actuall 
review.

> That is, rather than named parameters *or* (to my mind) misusing 
> manipulators,
> simply use function calls to set those options.  That even permits named
> functions for related options like classic_locale(), nothrow(), etc., 
> easily providing
> additional flexibility and expressiveness.

Yes, as I said I do not have anything major against this apart from the fact 
that I feel Boost.Parameter might fire better accomplishing that.

> Manipulators added to that convert expression, then, are ordinary
> manipulators that affect the underlying stream.  There are none
> that apply to the convert framework while the rest apply to the stream.
> Separating the interface to those two parts of the machinery is a wise
> course, don't you agree?

Well, out of laziness or some other reason I am guilty of simply typing 
"convert::from >> std::hex >> locale". I know 'std::hex' and 'locale' affect 
different underlying parts. However, on the application level it does not 
seem that important to me -- in the end it shapes up the conversion. So, I 
am not that determined about "separating the interface to those two parts of 
the machinery". It's like my transmission stick and the steering wheel are 
two different interfaces to two different parts of machinery. However, I 
would not probably mind if I could handle steering and transmission with 
just one thing.

V.