[boost] Re: Named params lib review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-11-22 14:34:36

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

The only fact here is that you are making that statement. Let's take you
"more-capable" interface and implement solution for simple problem. Let then
take my interface and implement the solution for the same problem using my
"less-capable" interface. Let than compare which variant is easier and
shorter. And that would be *the fact* (it's still matter of
taste/preference, but I hope we will be able to see it clearly). Until that
time you statement:

"You can't implement the same compile-time logic with less keystrokes"

*is* a matter of opinion and not a fact.

> > If parameter is *required*, you will get a compile time error . If it's
> > optional you may (it's not necessary 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.

I may say the same thing, but pressing different points: your design
sacrifices flexibility and usability for ... compile time switch of function
implementation.

My design based on a two facts:
1. it's perfectly ok to omit optional parameter in function invocation
2. If parameter is optional why invocation should fail to compile if it's
missing?
3. it's ok to switch function implementation at runtime based on
presence/absence of function parameter

> > 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] );
> > }

> > No you couldn't. Above wouldn't compile.
>
> Mmmm.... why not?

Because p[i2] fails to compile if i2 is missing.

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

Not even small example? Pseudocode? Pity. I would be much more easier to
discuss the differences.

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

Do you mean: without need to change other overloads of the same function?

You see, it's difficult for me to imagine this situation since in a majority
of the cases I would be using *single* public function:

foo( Params const& )

that cover all possible combinations of parameters. If you could just
explain (give an example) when I would need more.

> >> >> > 4. Unlimited number of parameters support
> > What about type restrictions?
>
> If you want them, you specify it.

IOW library wouldn't be able to provide automatic support for this.

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

So you solution either force limit on number of parameter or does not
provide automatic type checking. Is this right?

> > 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.
>
> That the examples I have shown don't convince you is not
> surprising.

Did you? Did I missed them?

> > It's good, that you confident though.
>
> Your sarcasm is unwarranted.

Well. Since you believe you are allowed to state "I am confident, that I am
right", I believe I am allowed to be a bit sarcastic (especially since I
feel that you statement does not have enough foundations)

> -- 
> Dave Abrahams