[boost] Re: Named params lib review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-11-22 09:56:57

> >> > 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. Just because you put
something into library header doesn't make it more powerfull. It should
really bring some advantages and simplify (enhance usebility) function
implementation in user's code.

> >> > 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.

> >> > 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.

> 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.

> >> > 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?

> 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 showed several. All I sew from you so far in not convincing.
It's good, that you confident though.

> Cheers,
> -- 
> Dave Abrahams

Gennadiy