[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.