[boost] Re: Named params lib review

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-22 07:48:08

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>> > 1. parameter type enforcing
>>
>> Check.  You provide a simpler and less-capable interface.  Of course
>> it would be easy to add a simple and less-capable interface on top of
>> our general one.
>
> Could you please ground you statement about "less-capable". With
> specific examples.  If you mean something amoung the lines
> "is_movable" check. 

I do.

> Look at my responce here:
>
> http://lists.boost.org/MailArchives/boost/msg75147.php

I saw that.  You are basically saying the capability isn't important.
We can agree or disagree over that point, but the fact is that the
interface you support is still less-capable.  I'm trying to bring
this back to objective reality.

>> > 2. default value support
>>
>> Details, please?  Please show the differences (I've clearly lost track
>> of this thread).
>
> template<typename Params>
> void foo( Params const& p )
> {
>    you interface
>     int ind = p[index | 0 ];
>    my interface
>     int ind = p.has(index) ? p[index] : 0;
> }

If that's your interface, I don't see how the following statement of
yours can also be true:

  > version you refer to does produce compile time errors facing
  > missing required parameter.

Meaning that if there's no default for index, in your code:

  int ind = p[index];

will still compile.

>> > 3. option parameter support
> optional actually. Sorry
>>
>> Details, please?
>
>>From other thread:
>
>> > void foo_impl( int i1, int i2 ) {...}
>> > void foo_impl( int i1 ) {...}
>> >
>> > template<typename Params>
>> > void foo( Params const& p ) {
>> >     if( p.has(i2) )
>> >         foo_impl( p[i1], p[i2] );
>> >     else
>> >         foo_impl( p[i1] );
>> > }

I'm not sure what you're saying.  With the addition of "has"
functionality (which we've long ago agreed should be added), you could
do this with our design.  We can agree or disagree that this approach
is a good idea or not, but the fact remains that your design has no
support for non-intrusive overloading (e.g. via ADL).

>> > 4. Unlimited number of parameters support
>>
>> If I understand what you're saying, no you don't.
>
> Why? I could have as many parameters to function as I want since I do not
> try to combine under the hood of single keywords structure.

I understand that.  I'm saying you don't have a new capability here.

>> Don't forget, we have the overloaded comma operator.
>
> Don't you still need to use keywords structure? 

You don't have to specify it up front unless you want to do overload
resolution control.

Okay, thanks, I think I understand your value decisions and design
choices here.  I was asking because I was concerned that your simpler
design might have been an improvement, but I'm now confident we got
closer to the sweet spot in the design space, at least from my point
of view.

Cheers,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com