New Specializers For CLOS

[Bobrow.pa@Xerox.COM]

There are two "hacks" in the current writeup of the MOP designed to make the
current generic function specializer mechanisms work in two special cases.

The current argument specializers in CLOS use either the identity of argument to
a given object, or membership in a set defined by the type(s) of the instance.
Two extensions have been suggested: basing method selection on a subclass
(subtype) relationship directly for class objects; and basing method selection
on the metaclass of a particular argument.   

1)  Choosing a method based on the instance metaclass

Current Hack:
The specification notes that (slot-value instance slot-name) is converted to
(slot-value-using-class class instance slot-name).  This conversion allows the
metaclass of the instance to play a role in the selection of the method used. 

Proposal:
Add a specializer form
  (metaclass <class>)
A method with such a specializer would be applicable if the metaclass of the
object bound to the argument is of type specified by <class>.  

Example:
(defmethod slot-value ((instance (metaclass 'standard-class)) slot-name) ...)

would allow slot-value to be a generic function whose method selection involves
the metaclass.

Issues:
a) Should <class> be a form to be evaluated, or a class-name. 
  Proposal: It should be a form that should evaluate to any type specifier

b) All methods specialized on a generic function must agree on whether the class
or metaclass of a particular argument is to be used for discrimination.  How
should this be noted in the generic function? 
  Proposal: A generic function argument list can contain a require argument that
looks like (metaclass <argument name>).


2) Choosing a method based on a subclass relationship
  Current Hack:
The current metaclass protocol uses a "prototype instance" to select a method in
certain cases where the identity of the particular instance is not important.
It is used because one cannot specify a method somehow associated with the class
that will be slected by an argument that is that class or a subclass.

Proposal: 
Add a specializer
    (subclass <class>)
A method with a subclass specializer on an argument is applicable if the
argument is of type <class> and is a subtype of the given class.

Example:
  (defmethod class-expand-defclass
     ((class (subclass 'standard-class)) defclass-form) ...)
will choose the expansion method based on the class specified as a metaclass.

Issues:  Same as for metaclass, and with corresponding answers.


------
ARGUMENTS FOR THE CHANGE

This is an obvious extension of current practice,
based on the "set" semantics of types.
It does not cost much code in the kernel.
It allows elimination of a couple of "hacks" in the current kernel

ARGUMENTS AGAINST THE CHANGE

The current hacks work. 
This effects chapters 1 and 2.
People have not had much experience with these kind of features
  (They second has been used quite successfully in KEE)