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 ([EMAIL PROTECTED])
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
