Oleg Abrosimov <beholder@gorodok.net> writes:
You're not saying what you mean by "reuse." We think reuse is very possible with the Parameter library, so it's quite unclear what you might be referring to.
libraries are all about reuse. boost::parameter is not an exception of course.
By reuse I mean configuration reuse in client code.
By "configuration" I take it you mean something equivalent to "ArgumentPack."
Not reuse of boost::parameter library in other libs. Consider: foo(width = 2, height = 1); // ... some code ... foo(width = 2, height = 3);
vs.
TFooParam p; p.width = 2; p.height = 1; foo(p); // ... some code ... p.height = 3; foo(p); // p is reused here
That's also possible with the parameter library; p would be an ArgumentPack.
The drawback in such a scenario is reduced visibility, because of 'p' can be initialized too far from the second call of 'foo'. But in practice most common scenario is to initialize 'p', call 'foo(p)', then modify 'p' slightly and call 'foo(p)' again. It means that visibility is preserved.
Is that common? For what interface?
- ambiguity with other language constructs (it is very important drawback. As I realized from parameter docs,
You're not being specific enough here either. I can't imagine what ambiguity you mean.
consider:
void new_window(char const* const, int = 10, bool = true);
int main() { int width; bool titlebar; new_window("alert", width=10, titlebar=false); return 0; }
call to new_window can not be translated unambiguously by reader in presence of named params. I expect that compiler will complain, but reader can be fooled by such a call, especially if we change it a bit:
int main() { new_window("alert", width=10, titlebar=false); return 0; }
What is a 'width' here? parameter name? or some variable in global scope?
Oh, sure, Fred Bertsch's problem. Because of that we instituted a new naming convention (and associated macros for defining keyword objects). Now that would read: new_window("alert", _width=10, _titlebar=false);
great effort should be made to make such an ambiguity possible.
Why would we want to make an effort to enable ambiguities?
It would be better IMO to eliminate this efforts in implementation and the ambiguity in one shot - provide special may be auxiliary structure - like syntax to use parameters)
It's unclear what you mean.
I mean that significant amount of work should be done to allow named parameter syntax that can be ambiguous as was shown above.
Why should it?
The idea I was trying to explain is simple - May be it is possible to find a way to achieve both goals - unambiguity and reduce of efforts required to enable named params usage.
I think a suitable naming convention is enough. Or you can use qualification to refer to parameter names.
IMO the implementation complexity doesn't matter as long as it works and gives comprehensible feedback when misused. Do you inspect the source code of your compiler and complain about its implementation complexity?
We are living in very different worlds. and it is good for you. I'd be happy if I can say the same as you've said here. Not many of as are paid for libraries writing. My job is application programming. It is always done in a high time pressure.
That's why you need libraries that work reliably.
I'm writing several functions per day. Most of them are used only by me to implement other functions. I _can not_ spend time to implement named params for each function that I wrote. It is completely impractical.
I agree in principle that it makes little sense to use named parameters in all your internal interfaces. But note, defining a parameter-enabled function hardly takes any time anymore, since Daniel W. created the new macros described in http://www.boost-consulting.com/boost/libs/parameter. It's almost the same as writing down the function would be if there were a built-in language feature. Cheers, -- Dave Abrahams Boost Consulting www.boost-consulting.com