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

From: Noah Stein (noah_at_[hidden])
Date: 2004-11-13 15:08:19

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Thorsten Ottosen
> Sent: Saturday, November 13, 2004 5:42 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Re: [Review] Named parameters library
> 
> "Noah Stein" <noah_at_[hidden]> wrote in message
> news:200411121528426.SM00924_at_enki...
> | > -----Original Message-----
> | > From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]]
> | > On Behalf Of Thorsten Ottosen
> | > Sent: Friday, November 12, 2004 2:47 PM
> | > To: boost_at_[hidden]
> | > Subject: [boost] Re: [Review] Named parameters library
> |
> |
> | > 1. Clearly, this is not nice
> | >
> | > window* w = new_window("alert", true, true, false, 77, 65);
> | >
> | > However, the amount of work needed to code parameters for this is
> quite
> | > large.
> | > A simple, effective way is just to do it like this:
> | >
> | > window* w = new_window("alert");
> | > w->set_resizable( true );
> | > w->set_height( 77 );
> | > ....
> | > and you might provide chaining to make it more concise. In addition
> there
> | > is
> | > no forwarding problems and you might have these
> | > functions anyway.
> | >
> |
> | What about the situation where you need to specify the parameters at
> | construction, e.g. the RAII paradigm?
> 
> I don't think I understand what you're saying.
> 

You presented a counter-example to show how the named parameters is
unnecessary.  You show that, quite reasonably, you can remove parameters
from the constructor by using post-construction functions.  The parameters
become explicitly identified due to the fact that the function names are
identification themselves, e.g. "true" obviously refers to the sizeable
attribute in your example although it's not obvious from the original
constructor.

I agree that your point is well made in the example given.  But that's only
one example.  There are many others.  My resulting question is: what's your
solution when the parameter list can't be reduced?  Frequently, I like to
avoid two-step construction and initialization.  I don't want every member
function to check to see if the object is truly available or uninitialized.

There are times that I can't avoid long parameter lists in my constructors,
especially when dealing with classes that sit just on top of hardware.  The
named parameters library looks like it could facilitate construction by
enhancing readability and default value handling.

I guess my point boils down to the fact that you gave one counter-example,
which I believe is not applicable in a number of cases.  Given that it's
not, it just seems premature to not accept.

-- Noah