[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: opaque type proposal
I suppose that the idea of using the <id> argument upward-compatibly for a
handler procedure isn't too bad, so I guess I favor restricting the argument for
now, but let's restrict it to a string rather than a symbol; symbols have a
distinct purpose, providing unique representatives of certain names, while
strings are better suited to this job. Actually, I don't care very much about
I agree that ``record type descriptor'' is better than ``record type'' for the
reasons Jonathan puts forward.
Jonathan says, ``I would oppose anything resembling TYPE-OF, since whenever you
have subtyping or polymorphism, there's no such thing as THE type of an object.
I don't see why it would be useful either, since you can always put
type-specific information (like generic operation handlers) somewhere else; e.g.
in the case of records, you can put it in the type descriptor.''
I understand that ``THE type'' is not well-defined, but it is possible to define
a particular structure of type ``names'' such that every object has a
most-precise name in that space. For example, having only one type-name for all
procedures effectively dodges the problem of polymorphism.
As for the idea of putting the type-specific information in the type descriptor,
this is something that only the implementation can do, not a specific user.
I think that a reasonable choice for type names is predicate procedures.
Suppose that RECORD-PREDICATE was required to always return the same, EQV?
procedure. Then for each object, there would be a unique most-discriminating
predicate defined by the language. Some procedure, perhaps called something
like VALUE-TYPE-PREDICATE, would map all objects into their distinguished type
I don't see anything ill-defined or modularity-breaking in any of this.
Alan is concerned that allowing single inheritance now might be a hinderance
later if we decide to extend to multiple-inheritance. I don't claim to be a big
expert, but it seems to me that all of the multiple-inheritance facilities that
I've seen have precisely the same simple single-inheritance semantics as a
special case. Alan (or anyone else), do you know of any exceptions to this? If
not, then I would think that we were fairly safe in going this far (and no