1.0.4.39: get rid of hardcoded mutex and spinlock slot indexes

[sbcl.git] / doc / manual / beyond-ansi.texinfo

diff --git a/doc/manual/beyond-ansi.texinfo b/doc/manual/beyond-ansi.texinfo
index 93929ec..2fc20c8 100644 (file)
--- a/doc/manual/beyond-ansi.texinfo
+++ b/doc/manual/beyond-ansi.texinfo
@@ -51,6 +51,22 @@ are:
 
 There is no record of what the second return value was meant to
 indicate, and apparently no clients for it.
+
+@item
+@tindex generic-function
+@tindex standard-generic-function
+@tindex funcallable-standard-object
+@tindex sb-mop:funcallable-standard-object
+@tindex standard-object
+@tindex function
+The direct superclasses of @code{sb-mop:funcallable-standard-object} are
+@code{(function standard-object)}, not @code{(standard-object function)}.
+
+This is to ensure that the @code{standard-object} class is the last of
+the standardized classes before @code{t} appearing in the class
+precedence list of @code{generic-function} and
+@code{standard-generic-function}, as required by section 1.4.4.5 of the
+ANSI specification.
   
 @item
 @findex ensure-generic-function
@@ -76,9 +92,9 @@ Where AMOP specifies @code{:declarations} as the keyword argument to
 @tindex function
 @findex sb-mop:class-prototype
 @findex class-prototype
-although SBCL obeys the requirement in AMOP for
-@code{validate-superclass} for @code{standard-class} and
-@code{funcallable-standard-class} to be compatible metaclasses, we
+although SBCL obeys the requirement in AMOP that
+@code{validate-superclass} should treat @code{standard-class} and
+@code{funcallable-standard-class} as compatible metaclasses, we
 impose an additional requirement at class finalization time: a class
 of metaclass @code{funcallable-standard-class} must have
 @code{function} in its superclasses, and a class of metaclass
@@ -87,14 +103,14 @@ of metaclass @code{funcallable-standard-class} must have
 @findex typep
 @findex class-of
 @findex subtypep
-At class finalization, a class prototype which is accessible by a
-standard mop function @code{sb-mop:class-prototype}.  The user can
-then ask whether this object is a @code{function} or not in several
-different ways: whether it is a function according to @code{typep};
-whether its @code{class-of} is @code{subtypep} @code{function}, or
-whether @code{function} appears in the superclasses of the class.  The
-additional consistency requirement comes from the desire to make all
-of these answers the same.
+After a class has been finalized, it is associated with a class
+prototype which is accessible by a standard mop function
+@code{sb-mop:class-prototype}.  The user can then ask whether this
+object is a @code{function} or not in several different ways: whether it
+is a function according to @code{typep}; whether its @code{class-of} is
+@code{subtypep} @code{function}, or whether @code{function} appears in
+the superclasses of the class.  The additional consistency requirement
+comes from the desire to make all of these answers the same.
 
 The following class definitions are bad, and will lead to errors
 either immediately or if an instance is created:
@@ -118,6 +134,13 @@ The following definition is acceptable:
 @end lisp
 and leads to a class whose instances are funcallable and have one slot.
 
+@tindex funcallable-standard-object
+@tindex sb-mop:funcallable-standard-object
+Note that this requirement also applies to the class
+@code{sb-mop:funcallable-standard-object}, which has metaclass
+@code{sb-mop:funcallable-standard-class} rather than
+@code{standard-class} as AMOP specifies.
+
 @item
 the requirement that ``No portable class @math{C_p} may inherit, by
 virtue of being a direct or indirect subclass of a specified class, any
@@ -156,6 +179,24 @@ for @code{slot-value-using-class} and @code{slot-boundp-using-class}.
 Note that application code may specialize on the @code{new-value}
 argument of slot accessors.
 
+@item
+@findex defclass
+@findex ensure-class
+@findex ensure-class-using-class
+@findex sb-mop:ensure-class
+@findex sb-mop:ensure-class-using-class
+@findex find-class
+@findex class-name
+the class named by the @code{name} argument to @code{ensure-class}, if
+any, is only redefined if it is the proper name of that class;
+otherwise, a new class is created.
+
+This is consistent with the description of @code{ensure-class} in AMOP
+as the functional version of @code{defclass}, which has this behaviour;
+however, it is not consistent with the weaker requirement in AMOP, which
+states that any class found by @code{find-class}, no matter what its
+@code{class-name}, is redefined.
+
 @end itemize
 
 @node  Support For Unix