|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-11-16 08:12:41
Joaquín Mª López Muñoz <joaquin_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk