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.