[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Amendments requiring additional writing



I looked through the Amendments handed out at the March X3J13 meeting,
with an eye to Dick's comments that some of them couldn't just be edited
into the document, but required significant additional writing.  Here is
suggested writing for the ones that don't already have suggested writing.
There might also be a problem of the suggested writings being hard to
understand, inappropriate, or incorrect; if so, we should discuss those
over the mail.

1-11: Replace the last paragraph with the following two paragraphs:

If in the new version of the class there is a local slot of the same
name as any slot in the old version of the class, the value of that slot
will be the same in both instances.  This means that if the slot has a
value, the value returned by {\bf slot-value} after {\bf change-class}
is invoked is {\bf eql} to the value returned by {\bf slot-value} before
{\bf change-class} is invoked.  Similarly, if the slot was
uninitialized, it remains uninitialized.

At the moment a class is redefined, if the new version of the class
contains a shared slot of the same name as any shared slot in the
old version of the class, the value of that slot will be the same
in both.  If in the new version of the class there is
a shared slot of the same name as any local slot in the old version of
the class, that shared slot is initialized to the value of the
corresponding {\bf :initform} option of the new class, or remains
uninitialized if the new version of the class does not specify or
inherit the {\bf :initform} option for that slot.  Shared slots
are not affected by the updating of an instance.

[1-11 will also get some changes to reflect the new scheme for
redefining classes, which does not use change-class, and some of the
existing text will be recycled as a description of change-class, however
I'm not trying to address those here.]

2-54: 

subtypep                        Function

Purpose:

The Common Lisp function {\bf subtypep} is extended to accept
class objects as type-specifiers.

Syntax:

{\bf subtypep} {\it type1} {\it type2}

Arguments:

{\it type1} and {\it type2} are type specifiers of any kind, including
class objects.

Values:

The first value is {\it true} if {\it type1} is definitely a
(not necessarily proper) subtype of {\it type2}.  The second value
indicates the certainty of the result.


type-of                         Function

Purpose:

The Common Lisp function {\bf type-of} is extended to accept an instance
of any class as its argument.  For instances of standard classes,
{\bf type-of} returns the class name when one exists, otherwise the
class object.

Syntax:

{\bf type-of} {\it object}

Arguments:

{\it object} is any object.

Values:

The result is a type-specifier such that
{\bf (typep {\it object} '{\it result})} is true.

If {\bf (class-of {\it object})} is an instance of {\bf standard-class},
{\bf type-of} behaves as if it was defined by

\screen!

(defun type-of (object)
  (let* ((class (class-of object))
         (class-name (class-name class)))
    (if (and class-name
             (cboundp class-name)
             (eq (symbol-class class-name) class))
        class-name
        class)))

\endscreen!


typep                           Function

Purpose:

The Common Lisp function {\bf typep} is extended to accept
class objects as type-specifiers.

Syntax:

{\bf typep} {\it object} {\it type}

Arguments:

{\it object} is any object.

{\it type} is a type specifier of any kind, including a
class object.

Values:

The value is {\it true} if {\it object} is of type {\it type}.