[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opaque type proposal
I think that I'm not very worried about your ``more mundane'' kind of problem,
viz. upward-compatibility when or if we get around to adding
multiple-inheritance. Isn't this entirely orthogonal to inheritance? For
example, what about when we get around to specifying a mechanism for
type-specific print operations, or any of a hundred other little options that we
might later decide to add? I don't see how the addition of these to
MAKE-RECORD-TYPE's argument list is likely to be any more painless/beautiful.
I'm also not convinced any longer that the issue of ``how not to make mistakes
now that hurt us when we later add multiple-inheritance'' is terribly important.
The notion of opaque types and sub-typing are reasonably well understood
entirely independently of any casual resemblance to an object-oriented
programming facility. If we're really so concerned that the facility we're
talking about now be extendable into an object-oriented programming facility,
then I submit that we should never decide on such an extension that cannot
handle this very simple and useful semantics.
In short, I'm having a hard time seeing the importance of this
upward-compatibility argument. All I want is this simple, straightforward
semantics for a very useful facility; it's just not clear to me that the
decision has the great weightiness of future impact that you perceive. Can you
explain your concern more fully?