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-03 18:51:08

> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> Gottlob Frege wrote:
>
>> And in addition to the unexpected effects, it just doesn't
>> read or look right.
>>
>>    from(str, 0)(more stuff);
> ...
> Here's another way to make it more explicit:
>
>   from(str, 0).with(more stuff);

Yes, I think I like Rob's 'with'. I feel this does rectify whatever "it just 
doesn't read or look right" there might be and it can be added quite easily 
to he existing interface. I personally like with() better than suggested 
before locale(), throw_(), etc. as it's only one new method to remember.

My only concern is that spelling out everything has limited value -- only 
for an uninitiated person. For a seasoned user having to explicitly spell 
out everything is likely to be irritating. I am certainly talking about my 
own experiences. Is "str.append(other-string)" really better/clearer then 
"str += other-string"? I expect anyone who grew up with C to appreciate the 
latter syntax. To me it is pretty much the same with "from(str, 0)(more)" as 
it deploys a known C++ technique of chaining with op(). That's why (given 
choice) while learning/playing I might probably start with

    from(str, 0).with(more stuff);

but once familiar with it, I'll likely switch to

    from(str, 0)(more stuff);

Maybe provide both?

>> If you really want the multiple function call syntax, could we
>> at least somehow put it first? ie (just one possible way), and
>> note that 'convert' has become 'converter':
>>
>>    converter<int>(locale_ = loc)(throw_ = true).from(str, 0);
>
> Why not with the syntax Dave has been suggesting:
>
>   converter<int>(locale_ = loc, throw_ = true).from(str, 0);

converter<int>(locale_ = loc)(throw_ = true)
converter<int>(locale_ = loc, throw_ = true)

To me the two above are only marginally different (and hardly visually 
different). Is it possible to identify what advantages of #2 there might be? 
As for #1, it is an instantly-recognizable and fairly common technique of 
chaining with op(). Unlike #2 it scales up with no issues. Providing a 
limited number of parameters is "cheating" as Alexantrescu puts it in his 
"Modern Design" book. :-) I understand that in practical terms it might not 
make any difference here... but why introduce a limitation when we do not 
have to?

As for converter<TypeOut>, I suspect it won't be able to take us far enough 
as it does not take into account TypeIn which is important for 
implementation specialization. People following this thread might remember 
that at one stage the implementation/interface was "convert[er]<TypeIn, 
TypeOut>". Then, I feel it was an improvement when we kept internally 
"convert[er]<TypeIn, TypeOut>" but externally were able to deduce TypeIn via 
a function with convert<TypeOut>::from(TypeIn).

That said, we certainly can re-visit that "convert[er]<TypeIn, TypeOut>". 
Then, we'll be able to do the suggested

converter<TypeIn, TypeOut>(local_=loc).from(type-in-value)
converter<TypeIn, TypeOut>(local_=loc)(type-in-value)
converter<TypeIn, TypeOut>(type-in-value)

To me it does have its own beauty and uniformity.

V.