Mat Marcus <[EMAIL PROTECTED]> wrote:
> --On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
> <[EMAIL PROTECTED]> wrote:
>
>> Joel de Guzman <[EMAIL PROTECTED]> wrote in message
>>> One can think of an optional<T> as conceptually a specialized but
>>> nevertheless, *IS-A* T, with the added specialization that it can
>>> be in a dead-uninitialized state. Maybe we'll call it a zombie
>>> object, undead object, you name it ;-)
>
> Hmmm. I'm not so sure about this. When I hear the phrase optional<T>
> IS-A T with an added specialization I am reminded of the phrase a
> Square IS-A Rectangle with an added specialization which usually gets
> folks into trouble. [Theoretical aside: I still see optional<T> as a
> sum/union, e.g. T + nil/ T | nil. That is I don't think we really want
> A + B < B (the sum/union of A and B) to be a subtype of A.]
This is the model that I was trying to *sell* from the very very start when
optional first came out for review. I never really understood why people
didn't see it that way. This is exactly the reason why I suggested looking
at other languages: to be able to get a solid grasp of the concepts behind
such a *thing* so as to be able to answer with utmost certainty the question:
: what is optional?
Some people say it is a container. Not! Some people say it is like a pointer
that can be NULL. Not! And this uncertainty leads us to confusion, and,
ultimately: missguided syntax and semantics.
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.
> Here's a question that tries to get to the crux of the pointer-like
> interface matter. Should T* and optional<T> both be models of a
> pointer-like syntactic concept?
Definitely No!
> I imagine that those who would answer yes do so because they may want
> to write generic code that uniformly handles pointers and possibly
> uninitialized variables. Those who answer no to the above question may
> prefer to write code that uniformly handles T and optional<T>. As you
> know, my (current) answer is no. There may be a third group who want
> both. The problem is that I find that the pointer-like interface is
> distracting, but that may be because I'm unfamiliar with the use-cases
> where you might want to handle T*'s and optional<T>'s uniformly or
> even replace raw pointers with optional<T>'s, since pointers also
> bring allocation issues with them. Instead I have been mainly focused
> on replacing T's with optional<T>'s. This is why I gravitate towards
> having an optional that models a syntactic concept such as PU that
> makes no mention of pointer-like syntax.
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.
> By the way, I would also like to thank you for your work on optional
> and your contributions to boost. I also appreciate your open
> discussion of the design of optional and optional-like classes. My
> posts are just those of a potential user who is interested in finding
> the right point in the design space for my needs. If my use cases or
> arguments prove useful to others or if optional is influenced to meet
> more of my needs, then of course I will be pleased. If not, I'm still
> learning about the design space from you and others on this list, so I
> benefit either way.
Same here. I would certainly hope to hear more from you. In fact,
I wish to hear more from the type-theory people such as Mat and Vesa
;-)
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
