Two points about the Named parameters library
Hello, This is not a review of the Named params library. I'd just want to make the following two points about it: 1. Some have considered this library as a means to gain experience about named parameters interfaces for possible inclusion into the standard as a built-in facility. I think this won't happen, since this issue has already been discussed (and rejected) prior to C++98. The library does not raise (AFAIK) any new issue about the suitability of such interfaces, so why should the comittee change their minds. So, we'd better consider named_params as a utility on its own, without hoping for future built-in support. 2. I think the docs miss an important point. Consider a final user exposed to a named_params-powered interface. Of course this user is not concerned about the implementation of the interface, or about the named_params lib, for that matter. Instead, she should be presented the interface as if named params were a built-in facility. A possibility: void foo(int :x:=0,int :y:=0,std::string :msg:="") foo does so and so... :x:,:y: and :msg: are named params that the user can resort to in order to subvert the traditional argument-by-position invokation interface. For instace: foo(msg="hello"); I don't claim this particular documentation example is any good (in fact, I found it rather bad), but I hope you get the idea. named_params docs are the perfect place to propose and "standardize" a general syntax and wording to document named parameter interfaces for the final user. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz <joaquin@tid.es> writes:
Hello,
This is not a review of the Named params library. I'd just want to make the following two points about it:
1. Some have considered this library as a means to gain experience about named parameters interfaces for possible inclusion into the standard as a built-in facility. I think this won't happen, since this issue has already been discussed (and rejected) prior to C++98. The library does not raise (AFAIK) any new issue about the suitability of such interfaces, so why should the comittee change their minds.
It happens from time to time. Also the composition of the committee changes. We've had several promising discussions of the issue since C++98. Apparently there were some "problems" with the pre-C++98 proposals that many of us think are non-problems now.
So, we'd better consider named_params as a utility on its own, without hoping for future built-in support.
2. I think the docs miss an important point. Consider a final user exposed to a named_params-powered interface. Of course this user is not concerned about the implementation of the interface, or about the named_params lib, for that matter. Instead, she should be presented the interface as if named params were a built-in facility. A possibility:
void foo(int :x:=0,int :y:=0,std::string :msg:="") foo does so and so... :x:,:y: and :msg: are named params that the user can resort to in order to subvert the traditional argument-by-position invokation interface. For instace: foo(msg="hello");
I don't claim this particular documentation example is any good (in fact, I found it rather bad), but I hope you get the idea. named_params docs are the perfect place to propose and "standardize" a general syntax and wording to document named parameter interfaces for the final user.
Good idea. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
David Abrahams -
Joaquín Mª López Muñoz