|
Boost : |
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-12 15:47:01
Hi Dave & Daniel
Here are some general comments on the library:
- What is your evaluation of the design?
---------
no comments
- What is your evaluation of the implementation?
---------
no comments
- What is your evaluation of the documentation?
---------
seems ok, though I miss what impact it would have on performance.
- What is your evaluation of the potential usefulness of the library?
---------
low
- Did you try to use the library? With what compiler? Did you have
any problems?
---------
no, no.
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
------
a glance
As always, please remember to clearly state whether you believe the
library should be accepted into Boost.
--------
I think it should not be accepted. My main motivation is that I think it
promotes an unsound
growth in function interfaces. I also miss a comparison of other techniques
(eg. bgl_named_params, named_constructor_pattern) to do the same and an good
explanation why
this approach is superior.
Let me elaborate.
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.
2. what happens, then, if I don't have an object, but a free-standing
function?
a) wrap the function in an object
b) do as in http://www.boost.org/libs/graph/doc/bgl_named_params.html
c) provide overloads of functions that pack related parameters together or
simply add defaults
I must admit I'm a bit sceptical about functions when they start having more
than 3-4 arguments; there is almost
always some abstraction lurking just waiting to be done.
-Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk