#

## Issue SLOT-VALUE-METACLASSES Writeup

    Issue:              SLOT-VALUE-METACLASSES
    References:         SLOT-VALUE (CLOS chapter 2)
    		    SLOT-UNBOUND
    		    SLOT-MAKUNBOUND
    		    SLOT-BOUNDP
    		    SLOT-EXISTS-P
    Related issues:     Issue CLOS-CONDITIONS
                        Issue CLOS-CONDITIONS-AGAIN
    Category:           CLARIFICATION, CHANGE
    Edit history:       V1, 09 May 90, Sandra Loosemore
                        V2, 13 May 90, Sandra Loosemore (update discussion)
    		    V3, 29 May 90, Sandra Loosemore (clean up)
    		    V4,  1 Jun 90, Gabriel (only proposal SPECIFY)
    		    V5, 06 Jun 90, Sandra Loosemore (three proposals)
                        V6, 11 Mar 91, Sandra Loosemore (one proposal)
                        V7, 26 Mar 91, Sandra Loosemore (amendment from meeting)
    Status:             V7 (proposal LESS-MINIMAL) accepted by X3J13, Mar 1991

    Problem description:

    The description of the function SLOT-VALUE in CLOS chapter 2
    requires it to be implemented using SLOT-VALUE-USING-CLASS, which
    is not defined in the standard.  Because of this omission, it is
    not clear on what metaclasses SLOT-VALUE is defined.

    There are similar problems with the description of SLOT-UNBOUND
    (references SLOT-VALUE-USING-CLASS), SLOT-MAKUNBOUND (references
    SLOT-MAKUNBOUND-USING-CLASS), SLOT-BOUNDP (references
    SLOT-BOUNDP-USING-CLASS) and SLOT-EXISTS-P (references
    SLOT-EXISTS-P-USING-CLASS, which is not even in the current MOP
    draft).

    It is stated in CLOS chapter 2 (in the section "Integrating Types
    and Classes") that calling SLOT-VALUE on an instance of a built-in
    class signals an error, but nothing is said here about the other
    functions.

    Proposal (SLOT-VALUE-METACLASSES:LESS-MINIMAL):

      (1) Remove references to SLOT-VALUE-USING-CLASS,
          SLOT-MAKUNBOUND-USING-CLASS, SLOT-BOUNDP-USING-CLASS, and
          SLOT-EXISTS-P-USING-CLASS from the language specification.  Add
          implementation notes to the description of SLOT-VALUE, SLOT-UNBOUND,
          SLOT-MAKUNBOUND, SLOT-BOUNDP, and SLOT-EXISTS-P which reference
          the corresponding functions in the metaobject protocol document.

      (2) Clarify that the function SLOT-EXISTS-P may be called with any
          object as its first argument, returning true if the object has a
          slot of the given name and false otherwise.

      (3) Clarify that the standard defines the behavior of SLOT-VALUE, SETF of
          SLOT-VALUE, SLOT-BOUNDP, and SLOT-MAKUNBOUND according to
          the metaclass of their first argument, as follows:
            STANDARD-CLASS -- all four functions work as already specified.
            BUILT-IN-CLASS -- all four functions signal an error.

      (4) Specify that the consequences are unspecified if any of the functions
          SLOT-VALUE, SETF of SLOT-VALUE, SLOT-BOUNDP, or SLOT-MAKUNBOUND are
          called on objects of any metaclass other than STANDARD-CLASS or
          BUILT-IN-CLASS.  An error might be signaled in this situation.  Note
          in particular that the behavior of these functions on condition
          objects and objects of metaclass STRUCTURE-CLASS is unspecified.

      Rationale for proposal LESS-MINIMAL:

        Point by point:

        (1) This gets rid of dangling pointers into hyperspace.

        (2) This corresponds to the current MOP draft.  It is also just what
            88-002R would say if the remark mentioning SLOT-EXISTS-P-USING-CLASS
            were removed.

        (3) This is clearly the "right" behavior.

        (4) This constrains SLOT-VALUE and friends from causing "crash and burn"
            errors, but doesn't overconstrain implementors.

    Current Practice:

      I don't know.

    Cost to Implementors:

      Probably small for any of the proposals.

    Cost to Users:

      Probably none.

    Cost of non-adoption:

      Part of the language specification will be left vague and
      confusing.

    Performance impact:

      None.

    Benefits:

      The language specification is made more concise.

    Esthetics:

      Making this point clear would be an improvement over leaving
      it unspecified.

    Discussion:

      This writeup has undergone a lot of revision because both the MOP
      document and people's perceptions of it have also been undergoing change.
      It has been difficult to find a balance between not permitting "crash
      and burn" errors and giving implementations freedom to support
      additional behaviors via the MOP.

      Gregor says:

        The MOP draft says very little about STRUCTURE-CLASS.  What it used to
        say about STRUCTURE-CLASS was removed in response to concern that it
        would make it more difficult to build delivery systems (a concern which
        I don't share by the way).  But, one thing the current draft does say is
        that SLOT-EXISTS-P won't ever signal an error.

        I guess my suggestion for X3J13 would be to be compatible with the MOP
        draft on SLOT-EXISTS-P and "allow implementations to extend" what
        happens when the slot-xxx functions are called on structure and built-in
        instances.

      It's assumed that, for item (1), the editor will make the implementation
      notes say something that agrees with the current MOP document.

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