[boost] Re: Re: Re: Re: [review] Formal reviewof the SmartContainerlibrarystarts today

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-06 09:28:15

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:41640494.6000403_at_torjo.com...
|
| > |
| > | Another problem, IMO, is that client code will need to be more
| > | complicated, in order to find out if a value is null or not.
| >
| > I don't understand that. One of the objectives of a null object is that
you
| > don't have to
| > worry about a value being null.
|
| really?
| I thought the purpose of null was to say "there's no object here. You
| can't do anything with me other than compare other pointers to me."

in the above a "null object" is an intance of a class and "null" is 0.

have you read the referenced paper?
(http://www.two-sdg.demon.co.uk/curbralan/papers/europlop/NullObject.pdf)

| > | > | And, for each new (virtual) function you add, you should update the
| > | > | null_object class - which I think can turn into a maintenance
nightmare
| > :(
| > | >
| > | > if your inheritance hierarchy contains N distinct classes, you would
need
| > to
| > | > add N implementations of that virtual function anyway, right?
| > |
| > | Not necessary... I can add one implementation, and some of those
| > | distinct N classes don't have to override it ;)
| >
| > you could insert the null object class between the abstract base class and
the
| > leaf classes.
|
| I've never seen a design like this, would never do something like this
| myself,

why not? It is quite common to have some class like this since we want to keep
the
base class fully abstract (as you would like to ensure minimal rebuilds).

| and I think I would really dislike any design that exibits this.

why?

Anyway, I don't really see how adding *one* extra function is a maintenance
nightmare. Keeping
track of 0's seems much closer to a maintenance nightmare since it affects
*all* function calls on the container.

| > It might be worth to have the existing interface if users want to try
changing
| > from vector<string> to ptr_vector<string>
| > just to see what happens.
| >
|
| I don't like phrases like "hey, let's change from std::vector to
| std::map, just to see what happens" (I know I exagerated a bit). When
| you change something, you should have a reason, and know what you're
| doing (tradeoffs, etc.).

Ross Boylan thought it was important.

br

Thorsten