--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola <[EMAIL PROTECTED]> wrote:
Joel de Guzman <[EMAIL PROTECTED]> wrote in messageOne 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.]
Theoretically, yes. But there are practical barriers here.
Unfortunately, in C++ subclassing is the only subtying mechanism, but you can't subclass a non class type, so you can't subtype an arbitrary T. IOWs,
Enter (syntactic) concepts and models thereof.
there is no way to completely implement an optional<T> which *IS A* T.
As I said above I'm not sure that I would want to.
[snip]
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?
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.
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.
Thanks, Mat _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
