Re: [boost] [convert] Now with Boost.Parameter interface.

Subject: Re: [boost] [convert] Now with Boost.Parameter interface.
From: Vladimir Batov (vladimir.batov_at_[hidden])
Date: 2009-07-06 16:55:50

> Gottlob Frege <gottlobfrege <at> gmail.com> writes:
> 
> ...
> 
> 0. using named parameters - is this still debatable, or pretty much decided

I'd say anything is debatable and open for a discussion. Although some aspects
have been discussed at length when the thread was somewhat more active.

As for "decided" it feels too hard a word as people have varying opinions and
preferences and I am inclined to try to accommodate those preferences (if
possible) rather than "decide" on something. I am trying not to decide on
anything but rather let pieces fall off based on the usage experience. I admit
mainly using my own experience as a guide as I do not have much other input.

As for named parameters, the interface is there and I was not rushing to take it
out as I remember some people argued strongly in its favor. My only
complain/observation was that my personal impression was that it was only of
limited usage (for locale and throw). I was not alone advocating that stretching
it further (radix, etc.) was counter-productive. 

> 1. how to list params:  (locale_ = locale)(throw_ = true) vs (locale_
> = locale, throw_ = true) vs ((locale_ = locale, throw_ = true))

It's pretty much "decided"... for now. :-) Simply because ((...)) looks very odd
and I personally do not want to give that syntax the user. Then, (,) (as I
understand) has its limitations and requires deploying Boost.Parameter macros
which I am not comfortable with. Then, the ()() chaining syntax is
standard/familiar, scales well and does not impose any limitations or typing
penalties. Sounds like a clear winner to me. The usual i-can-be-wrong disclaimer.

> 2. where to list params:  from(str, 0)(more stuff) vs from(str,
> 0).with(more stuff) vs (more stuff).from(str, 0)

When this discussion started (or rather re-started) I revisited the 'convert'
implementation and my design decisions. *I* am convinced that convert<TypeOut>
and even convert<TypeIn, TypeOut> do not work in general terms and the delayed
2-step specialization (1-st on the TypeOut via convert<TypeOut>, 2-nd on the
TypeIn via from()) is essential. Therefore, I *currently* feel that the
suggested (more stuff).from(str, 0) interface won't work. As for Rob's
from(str,0).with(more stuff) I do agree that it clears up whatever confusion
there might be and I am prepared to incorporate that if there is enough support
for it. I personally just can't help thinking that we are trying a bit too hard
spelling everything out -- it's not the trickiest of all interfaces (many Boost
components come to mind) and the seasoned users are unlikely to need 'with'. The
beginners will need to read the documentation anyway.

> 3. returning an int (well, whatever the To type is)

I'd love 'convert' to return TypeOut directly. I feel that it cannot. Have you
had a chance to read the documentation that is in the Vault with the 'convert'
implementation? There I tried to cover various scenarios. That said, I feel that
for simple cases 'convert' behaves *almost* like it returns TypeOut directly.
The only wrinkle was using the result in template functions like

template<class T> void foo();
foo(convert<int>::from(s));

For that there is

foo(convert<int>::from(s).value());
or
foo<int>(convert<int>::from(s));

> 4. use cases: function object, direct call, etc

I tried to cover the use-cases that I personally deploy and those that people
mentioned and I could think of in the document that comes with the
implementation (in the Vault). If you have some additional use-cases in mind,
I'll be happy to address and incorporate those as well.
 
> 5. ?

I'd encourage you to read the doc. and bring up whatever you feel not covered,
missing, incorrectly designed, etc. I am looking forward to your input.

V.