Re: New Specializers For CLOS

[Danny bobrow <bobrow.pa@Xerox.COM>]

> 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>.  


> 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.

jak says:
    The outlined problems are largely in Chapter 3 and the
    suggested solution will impact Chapters 1 & 2 as well. It might be
    better to look for a solution which does not impact Chapters 1 & 2,
    to avoid having to retrofit the changes.

    Since one of the characteristics of these new specializers
    outlined in the  proposal was that all methods on a generic
    function must  agree on these new specializers (i.e. either have
    them or the regular set, but not both), a new class of generic
    function is suggested and, with it, perhaps a set of associated
    macros  (DEFINE-METACLASS-METHOD ?) for conveniently defining the
    methods.

This can't be the case since you can have these kinds of specializers mixed with
ordinary specializers e.g.

(defmethod slot-value ((obj (metaclass standard-class))(name (eql 'foo)))
   ...)



The most compelling example for the "metaclass" specializer that we have come up
with is slot-value; but slot-value-using-class allows specialization on
either/both the metaclass and class.  This can be important in some cases.  Here
is a simple example.

(defmethod slot-value-using-class
    ((class standard-class) (object monitored-object) slot-name)
   (wait-until-object-is-not-write-locked object)
   (call-next-method)) 

Thus I think it is useful to continue to have slot-value-using-class.  In this
case, and because the new specializers affect chapters 1 and 2, I would say we
should leave these out, and keep in class-prototype and <x>-using-class