Re: opaque type proposal

[Pavel.pa@Xerox.COM]

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
this.

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
predicates.

I don't see anything ill-defined or modularity-breaking in any of this.
Comments?

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
more).

	Pavel