[boost] Re: Named params lib review

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-22 13:25:56

"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.
>
> And I am still disagree. Why is that interface less-capable if I
> could implement the same logic as with even less keystrokes. 

You can't implement the same compile-time logic with less keystrokes.
It's less capable because our design has a capability that yours
doesn't.  Not a matter of opinion, just a fact.

> Just because you put something into library header doesn't make it
> more powerfull.

I didn't say it was more powerful.  I said it was more capable.

> It should really bring some advantages and simplify (enhance
> usebility) function implementation in user's code.

Maybe so.  Whether or not the advantages I think the capability brings
are real or not appears to be a matter of opinion.  The fact that the
capability is in our design and not in yours is, well... a fact.

>> >> > 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.
>
> If parameter is *required*, you will get a compile time error . It it
> optional you may (it's not nessesary though) define default value. Any
> access to omitted optional parameter would produce runtime error.

Ah, I understand, now.  Thanks.  In that case my original statement
about your design that "it sacrifices compile-time type safety for
runtime checks" is in fact true.

>> >> > 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.
>
> No you couldn't. Above wouldn't compile.

Mmmm.... why not?

>> 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).
>
> Could you show me an example of "non-intrusive overloading" and how
> you design supports it.

Sorry, like Fermat I don't have time/space to write it down here ;-).
In shorthand, it's the ability to add new overloads of a top-level
(public) function template that uses named parameters without changing
the implementation of that function.

>> >> > 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.
>
> What about type restrictions?

If you want them, you specify it.  So maybe you have a way to specify
type restrictions without building a keywords structure, although you
do require people to bind the type restriction into the keyword
itself.  I admit that is a design difference.

>> 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.
>
> IMO you are yet to show single example that have prove a real
> advantage of you design.

I am not out to prove it to you.  I never try to change the opinion of
someone whose mind is already made up.

> I showed several. All I sew from you so far in not convincing.

:^).  That the examples I have shown don't convince you is not
surprising.  Likewise, none of the examples you've shown are
convincing to me, although at the beginning of this exchange I was
prepared to believe you had done something worthy of attention.

> It's good, that you confident though.

Your sarcasm is unwarranted.

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