[boost] Re: Re: Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-13 17:09:39

"Augustus Saunders" <infinite_8_monkey_at_[hidden]> wrote in message
news:20021213213610.12650.qmail_at_web41309.mail.yahoo.com...
>
> Fernando Cacciola wrote:
>
> >And pointers have historically been used to deal with optional
> >objects precisely because they model this concept.
>
> I think this is important, and so I want to dwell on it for a moment.
>  For many years, if a programmer needed optional functionality, she
> used a pointer.  There are a large number of existing libraries and
> APIs that use pointers to convey exactly this notion.  A pointer is
> essentially a defacto standard for this usage.
>
> Consider one more time, why do iterators look like pointers?  I
> wouldn't be surprised if a similar discussion took place back in the
> day:
>
> A: "I've got it!  Make iterators look like pointers!"
> B: "Hmm... That might confuse people.  They aren't really pointers."
> A: "You're right, some operators won't work on iterators."
> C: "On the other hand, it would be convenient."
> A: "Exactly! "
> A,B,C: (thinks real hard)
> C: "Also, if we make iterators look like pointers, then we can write
> generic code that takes either.  That way, we can interface to legacy
> systems with generic code."
>
> Eventually, they come up with concepts, which at the time I'm sure
> was a radical idea.  If there weren't already a large number of
> libraries that use this idiom, then generic code wouldn't really
> benefit.
>
> Yes, this generic code is hypothetical right now.  Since the
> OptionalValue concept has not been defined, nobody has tried to use
> it.  If we do define it and release it into the wild, will it lead to
> better libraries?  Consider your OS of choice's system APIs.  How
> many functions take or return pointers for this purpose?
>
> Please do not dismiss the pointer interface until you have considered
> this.  And remember that if you push hard enough, you will discover
> that smart pointers and iterators aren't really pointers.  The
> equivalence doesn't need to be absolute; just *useful* and *safe*.
>
I couldn't agree more.
In fact, I think the OptionalValue concept has been implicitly defined for
decades and this is why I prefer the pointer-like interface even if it
requires the poisoned relops.

I realize now that part of the confusion was introduced by the poor
documentation which didn't set the concepts straight. (which of course was a
direct reflex of my poor understanding of the issues)

Thanks to the clear arguments made by the reviewers, I see the picture a lot
more clear now.
Specially the fact that optional<> is itself a container, or perhaps, a
union of T and nil_t.
But your previous post were you developed those concepts were very helpful
as an argument to keep the pointer-like interface.

I have a deeper understanding of the issues involved now and I'm deeply
reworking the documentation.

Of course, I will formally present the OptionalValue concept on the
documentation, and you will be credited for that :-)

--
Fernando Cacciola