Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at