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.