From: "Stewart, Robert" <Robert.Stewart@sig.com> 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.