[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Kim A. Barrett <kab@CHARON.MIT.EDU>, Jon L White <firstname.lastname@example.org>
- Subject: Class STANDARD-SLOT-DESCRIPTION
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 29 Aug 90 16:33 EDT
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: <9008291501.AA12624@charon.MIT.EDU>, <9008291529.AA03768@caligula>
Date: Wed, 29 Aug 90 11:01:33 EDT
From: kab@charon.MIT.EDU (Kim A. Barrett)
I recently found another class name in 88-002R which may not have been
officially blessed. The DOCUMENTATION generic function has a primary
method specialized on the class STANDARD-SLOT-DESCRIPTION. I have not
been able to find any other mention of this class in 88-002R or the
draft standard, and it was not included in either of the issues from
the 6/90 meeting which made some of the random CLOS metaobject classes
official (TYPE-OF-AND-PREDEFINED-CLASSES and SANDRAS-TRIVIAL-ISSUES).
I think what you are seeing is that much of the text in chapter 2 was written
with the assumption that chapter 3 would exist. When chapter 3 was goal-reduced,
chapter 2 was not rewritten to reflect that fact.
If we are going to be consistent about these, then we should also have
a SLOT-DESCRIPTION class (with the exception of OBJECT, for every
class named STANDARD-xxx we currently have a class named xxx). Note
also that the most recent draft of CLOS Chapter 3 I've seen (dated
6/6/90) calls these classes STANDARD-SLOT-DEFINITION and
SLOT-DEFINITION. I personally have a mild preference for DESCRIPTION
rather than DEFINITION.
I prefer the spelling DEFINITION over DESCRIPTION. DESCRIPTION sounds
to me like a documentation string rather than an object.
Do we want to say anything at all about these classes in the standard?
Since I don't think they are very useful without a metaobject
protocol, perhaps we should just forget them and remove the reference
from the description of the DOCUMENTATION function.
I don't see any point in documenting methods specialized to metaobjects when
we don't have a metaobject protocol. Documenting the methods is mainly for
the benefit of users defining their own methods, so they know where the
system methods are and whether they will be shadowing them or not. But in
the absence of a metaobject protocol users can't usefully define their own
methods. However, maybe there is some reason I'm not seeing why these
methods should be documented in chapter 2 rather than chapter 3, and hence
be included in the ANSI Common Lisp spec.
Date: Wed, 29 Aug 90 08:29:59 PDT
From: Jon L White <email@example.com>
Last winter, Moon and I came up with what seemed to be a de-facto
standard for a meta-object protocol -- not the "last word", but a
minimally useful subset that Symbolics, Lucid, and the latest PCL
could generally agree upon (I think Franz too gave assent by silence).
I don't think it was by silence. I vaguely remember Franz explicitly agreeing
that it was a good step.
This list included SLOT-DEFINITION and STANDARD-SLOT-DEFINITION as
class names, along with several score of "introspective" functions.
Dave sent out the entire proposal to firstname.lastname@example.org
on March 4, 1990.
Agreed. By the way, this was explicitly not proposed to be included in ANSI
Common Lisp, only to be a first step towards an agreed upon metaobject protocol
beyond ANSI Common Lisp.