Issue CLASS-OBJECT-SPECIALIZER Writeup

Issue:		CLASS-OBJECT-SPECIALIZER

References:	Draft 8.81, p.4-15

		Draft 8.81, Glossary

		88-002R

Category:	CHANGE

Edit history:	Version 1, 28-Mar-91, Kim Barrett

Status:		Proposal AFFIRM was approved at the 3/91 meeting


Problem description:


 It was recently noted that the 8.81 draft defines parameter specializer names

 to include class objects.  This inclusion seems to be without basis in

 decisions made by X3J13, and the editor believes it to be an editorial error.


 However, there has been previous discussion of exactly this question on the

 clos mailing list, in which the general consensus seemed to be that class

 objects should be permitted as parameter specializer names.


Proposal (CLASS-OBJECT-SPECIALIZER:AFFIRM):


 Affirm the wording in the 8.81 draft on page 4-15, which states that a class

 object may be used as a parameter specializer name.


Examples:


  (defclass foo-class () ())

  (defmethod foo-method ((x #.(find-class foo-class))) x)


Rationale:


 Not affirming the draft's wording would make parameter specializer names

 inconsistent with other parts of the language, since the use of class objects

 and class names are generally interchangeable when used as type specifiers.


 The draft already says this.


Current Practice:


 Lucid 4.0 and Chestnut's Lisp to C translator support this.


 Several other implementations probably also support this.


Cost to Implementors:


 Likely small.


Cost to Users:


 None.  This is an upwardly compatible change.


Cost of non-adoption:


 Some applications may already depend on this.  In the mail discussion of this

 question it was mentioned that CLIM may be using class objects as parameter

 specializer names.


Performance impact:


 None.


Editorial impact:


 None if accepted, since the draft already contains the necessary words.


Esthetics:


 Avoiding inconsistancy regarding the distinction between class objects and

 class names when used as type specifiers is more esthetic.


Discussion: