Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-09-01 20:52:24

On Tue, Sep 02, 2003 at 09:05:59AM +0800, Joel de Guzman wrote:
> My attempt to image "optional<T> as conceptually a specialized but
> nevertheless, *IS-A* T,  with the added specialization that it can
> be in a dead-uninitialized state." Is a feeble attempt to re-sell the idea
> of the concept that will be immediately obvious to the OO programmer. I
> never really understood why I wasn't able to sell the idea that an
> optional<T> is *REALLY REALLY REALLY* nothing else but a 
> union of T and nil.

It's been pointed out before, but to re-emphasize it: from a
type-theoretic standpoint, it is not the case that optional<T>-isa-T.
Rather T-isa-optional<T>.  (Dog-isa-Animal because Animal has more
possible values.)  I don't mind the suggestive conceptual
analogy/similarity, but when you get down to technicalities, the "isa"
relationship doesn't hold in the same direction you're saying (in your
first sentence above).

> I agree 200%. I think the *only* meaningful argument against this
> was posed by Brian. That, in C++, you cannot make X<T> be a
> drop-in replacement of T because implicit conversion will not
> allow code such as:
> 
>     struct A { void foo(); }
>     
>     template <class T>
>     void bar(T t) { t.bar(); }
> 
>     bar(A());
>     bar(X<A>()); // HERE
> 
> Unless:
> 
>     class X<T> : public T {...};
> 
> But then again, that's just a technical impediment.  

As I just mentioned in a previous mail, if bar() has the foresight to
expect this, it can use an adapter in its implementation to smooth out
this issue.  (E.g.
    template <class T>
    void bar(T t) { adapt(t).bar(); }
)

As a final aside, I think much of this thread is degenerating into
Parkinson's Bicycle Shed[*], with respect to "is it a
pointer/container/X?"  At this point, I think we know what set of
methods should be in the interface (indeed, there could be methods both
to return pointers and references; both to throw/fail-undefinedly, etc.)
and the names/documentation issues will fall out with more experience.
Just MO.

[*] See bottom of
   http://www.boost.org/more/discussion_policy.htm

-- 
-Brian McNamara (lorgon_at_[hidden])