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-06-30 05:00:50

> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
>
> [I'm sorry it took so long to reply to this!  I lost your post for a 
> while.]

Hi, Rob, it's nice hearing from you.

> [snip]
>> 2. Both interfaces
>>
>> #1        int i = convert<int>::from(str, 0) >> std::hex;
>> #2        int i = convert<int>::from(str, 0)(radix_ = 16);
>>
>> are currently supported. Should I move away from direct
>> manipulator support and remove #1?
>
> #2 provides an interesting, high level abstraction that seems attractive,
> but only applies to numeric conversions.  The purpose is the same
> as >> std::hex so, I don't see the value of radix_ when that manipulator
> is commonly known, documented in the literature, and well understood
> on sight.  I don't think users can add their own named parameters for
> convert(), so the library provided named parameters will occupy special
> status and shouldn't favor one sort of conversion above another.
> Consequently, use manipulators when available.

Yes, that is *exactly* the conclusion I've come to. #2 indeed looks cute and 
aestetically I much prefer #2... but it seems to be merely a sugar coating 
over #1. On the other hand, #1 hardly needs *any* explanations/support for 
the reasons you mention and that imho makes it a clear favorite. On top of 
it, I either do not see how named-parameters-based interface can be made 
user-extendable unless we pack all the parameters into ArgumentPacks and 
pass them to the user. Maybe that might be the way to pursue in the future 
but I feel we pretty much get all that right off the bat with ol' 
manipulators-based interface.

>> 1. Both interfaces (for locale and dothrow) are currently
>> supported:
>>
>> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = 
>> true);
>> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>>
>> Should I remove #1?
>
> You should remove #2, not #1.

Yes, that's what I *actually* meant to say back then. :-) Now though after 
having both around I am not sure. As I mentioned I do like 
named-parameter-based interface -- I find it pleasant aesthetically (I just 
happen to like op()) and friendly. However, while typing I find myself 
favoring the frugality and practicality of #2. It is probably because

1) #2 uses the same interface/notation as ">> std::hex" (I admit of being a 
consistency/uniformity freak);
2) #2 is less to type (#1 requires using namespace 
boost::conversion::parameter;) (surely a weak argument but it saves me a 
round trip to the top of the file to add 'using');
3) I do not seem to find any other use for the named-parameter-based 
interface beyond locale_ and throw_ (so that the support base for #1 is 
somewhat small... although this interface clearly scales better and more 
uniformly).

These are just my musings how I torn feel about both rather than serious 
arguments for or against.

Best,
V.