[boost] Re: [Review] Named parameters library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-23 17:07:10

"David B. Held" <dheld_at_[hidden]> wrote in message
news:cnjtn1$ho4$1_at_sea.gmane.org...
| Thorsten Ottosen wrote:
| > "David B. Held" <dheld_at_[hidden]> wrote in message

| because that is the problem Add() is solving in the first place!  Any
| refactoring will simply add unnecessary complexity to a problem.  I am
| arguing that Add(), with its unashamedly numerous arguments, is
| irreducibly complex.  Any attempt to refactor it will *increase*
| complexity, not reduce it through abstraction.

I'm just not convinced.

| > | Now, in this case, we are looking at functions that only get called
| > | from a small number of places (or even just one).  Thus, named
| > | parameters don't really help any.  But the fact is, long argument
| > | lists are not intrinsically evil.
| >
| > are they intrinsically good?
|
| Is mowing the lawn intrinsically good or intrinsically evil?  If you
| can confidently answer that question, I know a few philosophers that
| would like to talk to you.  Some things are amoral, and long argument
| lists is one of them.

it was you who used the term "intrinsically evil", not me.

| > [...]
| > 1. pack the values in an object
| > 2. send that object along to a function
| > 3. unpack the data from the object inside the function
| >
| > And I guess that is what you think is plain stupid.
|
| Yes, because you had to either: pack the values into an object having
| a c'tor with a lot of arguments (sound familiar?), or you had to create
| an object and set the members later, which sounds downright foolish to
| merely avoid long argument lists.
| > My point has been, however, that once you start making abstractions you
| >
| > 1. simplify interfaces
| > 2. makes it possible to define invariants for your data and hence localize
| > error-checks
| > 3. adds type-safety to the application
| >
| > (but I guess we don't have to go through the benefits of OO here.)
|
| And my point is, in order to implement those abstractions, you very
| often encounter the very argument lists that you were trying to avoid!!
| In fact, preserving invariants implies that you *need* to do all-at-once
| initialization in the c'tor!

depends on the invariant, I guess.

| > [...]
| > So if I were to do it all over, I would probably map my database tables to
| > classes instead of passing tuples of strings and intergers around.
|
| That depends on the application.  If the strings and ints make sense
| in a class, by all means pack them into a class.  But when the data
| gets entered the first time, from the "outside world", *someone*,
| logically speaking, has to pack that data into a class the first time;
| and I don't see anything wrong with that being a single function with
| a long argument list.  Nothing you have said thus far convinces me
| otherwise.

I'm not surprised; its pretty hard to convince you :-)

-Thorsten