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

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-22 07:40:13

On Nov 22, 2004, at 12:16 AM, Joel wrote:

> Joel de Guzman wrote:
>
> Re: defaults handling:
>
>> 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.
>
> Hi,
>
> Hmmm. I wonder why I got no response. Am I not making sense?
> I think this solution is doable. You still get a compiler error
> when a default is not available when unsupplied by the caller
> and IMO, it is superior because the default handling does not
> clutter the function implementation.

But on the other hand, with this method you don't have the ability to 
make the defaults depend on the other parameters passed to the 
function. In the BGL, we have lots of dependencies between parameters 
where we'll build, e.g., a property map based on the vertex index 
parameter (which may be defaulted) and the value type of a weight map 
(which may be defaulted).

This approach also forces me to name the result type, which can be 
rather annoying.

        Doug