[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Specializers For CLOS
> 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>.
> 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.
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
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.
((class standard-class) (object monitored-object) slot-name)
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