[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Random metaclasses for CL types
- To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Subject: re: Random metaclasses for CL types
- From: David N Gray <Gray@dsg.csc.ti.com>
- Date: Thu, 25 May 89 11:49:33 CDT
- Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU
- In-reply-to: Msg of 24 May 89 1901 PDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
- Sender: GRAY@kelvin.csc.ti.com
> 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?