[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Random metaclasses for CL types
> I think the real concern is that some implementations might wish to allow
> even the holy types to respond to these protocols. I think we don't want
> to prevent it.
But that is easily handled by allowing the implementation the freedom to
decide which classes are BUILT-IN-CLASSes; we don't need to change the
definition of BUILT-IN-CLASS.
> In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone
> writing a portable program couldn't devise a more portable solution to the
> problem, especially if there is alternative that is used if the
> (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)
> returns T.
> Are you thinking of a portable programming environment?
Suppose I were trying to write a portable inspector. If an object is an
instance of a built-in class, then probably all I can do with it is to
invoke the implementation-supplied DESCRIBE-OBJECT method, but if it is a
STANDARD-CLASS, then I can do interesting things with its CLASS-SLOTS
list. According to page 3-81 of document 89-003, CLASS-SLOTS simply
returns NIL for a BUILT-IN-CLASS, so how else would I know the difference
between a standard object that has no slots versus an object implemented
in some way that I can't look inside of?