Re: [boost] [Review] Named parameters library

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-11-18 02:31:38

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