Hi, I vote to accept the Named parameters library into boost. It fills a need that is lacking in C++.
- What is your evaluation of the design?
Very good. Some comments: 1) WRT DSL, I'm not quite sure about the syntax for defaults. Example: params[name | "unnamed"] I have a strong feeling that there's a better syntax but I am not sure what it is now. I read in the thread that the syntax params[name] | "unnamed" is not doable, but I'm not quite sure. Perhaps a clarification will set me straight. Having the default in the brackets seems to rather awkward. Perhaps: params[name].defaults_to("unnamed") is better? 2) Automatic Overload Generation Is it not possible to elide the use of macros? Instead of: template<class Params> void foo_impl(const Params&); BOOST_NAMED_PARAMS_FUN( return_type, function_name , min_arity, max_arity, keywords_type ); I'd very much prefer writing something like: struct foo_ { template<class Params> struct result { typedef void type; }; template<class Params> void eval(const Params&) const; }; named_interface<foo_, foo_keywords> const foo = foo_(); 3) Which brings me to my third point: I notice that BOOST_NAMED_PARAMS_FUN has a fixed return type. IMO, this is a big drawback of the macro aproach. The non-macro approach I presented is fully polymorphic WRT its return type. IOTW, the return type can be dependent on the arguments (Params). Oh and, also, I need to be able to generate the overloads through templates instead of auto generatng the overloads through a macro. Why is this important? I like the named interfaces a lot and I'd like to add the facility to Phoenix (BTW, the approach outlined above is reminiscent of phoenix::function). The two issues I mentioned above hinders me from using named interfaces. Fortunately, both appraoches are orthogonal. I can easily add the named_interface<foo_> overload generators from within Phoenix, so this is not such a big issue.
- What is your evaluation of the implementation?
Well written.
- What is your evaluation of the documentation?
Adequate but there's definitely room for improvement. For example, there is a section (2.2 Defining the forwarding functions) without any text at all; just code.
- What is your evaluation of the potential usefulness of the
library? I know the usefulness of named params from other languages. Even the humble HTML language has named parameters. Example: <img src="hello.gif" alt="Hello">
- Did you try to use the library? With what compiler?
Yes. VC7.1.
Did you have any problems?
No.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I've been following the development since the beginning.
- Are you knowledgeable about the problem domain?
Yes. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net