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-02 05:56:11

> From: "Gottlob Frege" <gottlobfrege_at_[hidden]>
> And in addition to the unexpected effects,
> it just doesn't read or look right.

   from(str, 0)(more stuff);

> really makes me think 'more stuff' happens AFTER the conversion.

Well, I am not sure I can agree that those mentioned "unexpected effects" is 
such a big deal. The "problem" with the deduced template parameters is the 
only "problem" I've come across so far. In fact, that issue is not unique to 
'convert' and 'convert' addresses that is a fairly standard way. Granted, 
not having that 'hack' would be better.

> This is one of the examples of why C programmers and many other
> language-ites just shake their heads at us. We can't seem to stick to
> writing code that even follows the rules of the language. (obviously
> the code, using a proxy, does follow the rules, but it doesn't look
> like it does).

I hear you. :-)

> 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);

I am not sure why 'convert' had to become 'converter' so for the moment I'll 
stick with what exists already. That makes it

int i = convert<int>(locale_=loc)(throw_=true).from(str,0);
vs
int i = convert<int>::from(str,0)(locale_=loc)(throw_=true);

I am not sure. I'll have to sleep on it. Something is drawing me to the 
syntax you suggest but I am not sure what it is. What I like about the 
existing syntax though is its incremental flowing style:

int i = convert<int>::from(str,0); // simple form
int i = convert<int>::from(str,0)(locale_=loc); // with locale
int i = convert<int>::from(str,0)(locale_=loc)(throw_=true);

The above looks more predictable and flows better for me.

> And as a bonus, I can reuse the 'converter' on the next line if I
> store it somewhere.

Yes, that functionality is already available (like one can use the same 
conversion with an algorithm) although maybe not in such an explicit form. 
That functionality was suggested, fairly straightforward to achieve within 
the existing framework, just did not get time to make it happen.

> And you can still use the simple 'convert' (without the er) if no
> extra params are needed:
>
>   convert<int>::from(str, 0)

What I feel uncomfortable with is that "if this, use converter, if that, use 
convert, if this, use one syntax, if that some other syntax". To me that 
lacks predictability which is the first step towards familiarity that leads 
to confidence and acceptance (something any library writer wants).

> And now it really does return an int.

After looking at the problem for a while I am not sure that 'convert' really 
returning a straight 'int' is achievable without denying many legitimate 
use-cases. Though I by no means can claim the last word in the domain.

V.