Boost logo

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?

- 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
    a) wrap the function in an object
    b) do as in
    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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at