Re: [boost] Re: [Review] Named parameters library

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-11-18 20:36:59

David Abrahams wrote:
> Doug Gregor <dgregor_at_[hidden]> writes:
> 
> 
>>On Nov 18, 2004, at 9:38 AM, David Abrahams wrote:
>>
>>>Daniel Wallin <dalwan01_at_[hidden]> writes:
>>>One possible alternative is
>>>
>>>    params.defaults_to("unnamed")[name]
>>>
>>>but I find that highly illogical to read, because the specification
>>>of the default precedes the keyword it's defaulting.
>>>
>>>However, Thorsten's prodding has made me wonder if we need || for the
>>>lazy case at all.  It seems as though
>>>
>>>    params.has(name) ? params[name] : something_else;
>>>
>>>is superior in every way except brevity.  And there will be
>>>substantial cases where it's briefer as well, because there's no need
>>>to build a function object for something_else.
>>>
>>>Am I missing something?
>>
>>"something_else" still has to compile, whereas with "||
>>something_lazy", "something_lazy()" does not have to compile.
> 
> 
> That too.  Okay, I was missing a lot.  That's what happens when
> there's a long gap between initial design and the review.

Here's another possibility: declare the defaults in the
foo_keywords class:

struct foo_keywords
   : boost::keywords<
         name_t
       , value_t
     >
{
     static string default_(name_t) { return "duh"; }
     static int default_(value_t) { return 123; }
};

With this approach, all default extraction is lazy.

Admitedly, it's more verbose. However, like in straight c++,
the defaults are part of the interface, not the implementation.
IMO, foo_impl's body is not a good place to place the defaults.
I imagine that in many (all?) cases, you'd want the implementation
to be hidden. Yet, doing so will also hide the defaults.
With this approach, the defaults can be placed in header files
as part of the interface.

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net