-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: Saturday, November 13, 2004 5:42 AM To: boost@lists.boost.org Subject: [boost] Re: Re: [Review] Named parameters library
"Noah Stein" <noah@acm.org> wrote in message news:200411121528426.SM00924@enki... | > -----Original Message----- | > From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] | > On Behalf Of Thorsten Ottosen | > Sent: Friday, November 12, 2004 2:47 PM | > To: boost@lists.boost.org | > 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