CLHS: Issue CONDITION-SLOTS Writeup

#

## Issue CONDITION-SLOTS Writeup

    Issue:         CONDITION-SLOTS

    References:    Condition System, version 18
                   Issue CLOS-CONDITIONS
                   Issue PACKAGE-CLUTTER
                   ANSI CL draft pp.5-4, 5-5

    Category:      CLARIFICATION

    Edit history:  3-Jan-90, Version 1 by Barrett
                   30-Apr-90, Version 2 by Moon (rewrite, just one proposal,
                     extend to cover all specified objects that have slots)

    Problem description:

      Pages 5-4 and 5-5 of the ANSI CL draft specification from last fall refer
      to slots of specified conditions.  However these slots were not put into
      the specification in a consistent way.

      CLOS-CONDITIONS:INTEGRATE, which was adopted by X3J13, changed condition
      slots to be the same as CLOS slots, but did not say that the specified
      conditions have any specified slots.  However, some people have taken it
      to mean that the condition classes defined by the standard all contain
      slots whose names are external symbols in the CL package which are
      STRING= to the specified initargs for creating conditions.  The ANSI CL
      draft specification was edited in some places as if this were true.

      Revision 18 of the conditions document, which was adopted by X3J13,
      refers to initialization arguments and accessors, but carefully avoids
      naming the slots themselves.  The philosophy of that document was that
      slots are only defined for programmer defined conditions, and that the
      only sanctioned interface for the standard condition classes is through
      the use of the defined accessor functions.

      A related, more general issue that PACKAGE-CLUTTER:REDUCE failed to
      address is whether there are naming restrictions on
      implementation-dependent slots of specified classes.

      This is Symbolics issue #8 and Loosemore issue #15 of 27 Feb 90.

    Proposal (CONDITION-SLOTS:HIDDEN):

      1. Clarify that no specified condition classes have any specified slots.
      The implementation of the required information storage by the specified
      condition classes is implementation-dependent.  We need to be clear that
      specified conditions are not required to have any particular slots with
      any particular names.  They -are- required to be the type of object that
      is able to have slots.  User-defined conditions -are- required to have
      slots with the names mentioned in the DEFINE-CONDITION form.

      2. Table 5-1 in the ANSI CL draft specification should not contain slot
      names, because they will not necessarily be accessible via WITH-SLOTS in
      the way people might infer.  Instead, the table should mention initargs
      and accessors.  For example, :FORMAT-STRING and
      SIMPLE-CONDITION-FORMAT-STRING -- but not the symbol FORMAT-STRING.

      3. Define that it is unspecified whether slots are involved in the
      operation of specified functions on instances of specified classes,
      except when slots are explicitly specified by the standard.

      4. Define that if in a particular implementation a specified class has
      slots that are not specified by the standard, the names of these slots
      must not be external symbols of packages defined in the standard nor
      otherwise accessible in the USER package.

    Rationale:

      Allowing the information storage to be implementation-dependent is
      essential to compatibility with existing systems, which may not represent
      this information in the "obvious" way.

      Specifying slots for the condition classes would require putting the slot
      names into the COMMON-LISP package, adding many symbols.

      Part 4 of the proposal repairs an omission in PACKAGE-CLUTTER:REDUCE.  It
      is necessary if users are to be able to define a subclass of a condition
      class (which is necessary whenever users define their own conditions) and
      give slots to their class without potentially interfering with
      implementation-defined slots.

    Current practice:

      Parts 1 through 3 are likely to be consistent with all existing
      implementations.  Part 4 is not known to be specifically violated by any
      implementation, but it might well be violated by accident.  I have not
      tested any implementations specifically.

    Cost to Implementors:

      Easy, all they have to do is keep slot names out of user visible packages.

    Cost to Users:

      Easy, all they have to do is use the specified accessors rather than
      SLOT-VALUE or WITH-SLOTS to access information in conditions.

    Cost of non-adoption:

      Substantially increased size of the COMMON-LISP package and considerable
      extra work on the ANSI CL specification to document all the slots.
      Porting problems for any code that defines its own condition types
      because of slot name collisions.

    Performance impact:

      None of any consequence.  SLOT-VALUE might be faster than calling an
      accessor in some implementations (although in most implementations it is
      slower, when not called from a method), but access to a slot of a
      condition never occurs in important inner loops.

    Benefits:

      Conditions will be specified as originally intended.

    Esthetics:

      Abstraction is better than mandating one particular implementation
      of information storage.

    Discussion:

      None.

Copyright 1996-2001, Xanalys Inc. All rights reserved.