[Openmcl-devel] (SETF FIND-CLASS)

[Gary Byers]

On Wed, 6 May 2009, Leslie P. Polzer wrote:

>
> Gary Byers wrote:
>
>> The primary method on (SETF CLASS-NAME) uses (SETF CCL::%CLASS-PROPER-NAME)
>> to update the internal proper-name slot.  (It's defined around line 1700
>> in "ccl/level-1/l1-clos.lisp".)  That method also worries about whether
>> the name's status as a type specifier changes and whether that conflicts
>> with type specifiers defined with DEFTYPE.
>
> I'm not sure to what extent it influences the callers of
> CCL::%CLASS-PROPER-NAME but its behavior does not match the
> spec definition of a proper name:
>
> ? (defclass foo nil nil)
> #<STANDARD-CLASS FOO>
> ? (defmethod class-name ((class (eql (find-class 'foo)))) 'zoo)

I liked my

(defmethod class-name (...)
   (case (day-of-week)
     ...))

example of a pathological case better, but sure.  The MOP says that
the generic function CLASS-NAME returns "the defaulted value of the
:name initialization argument that was associated with the class
during initialization or reinitialization."  It also says that:

"Portable programs may define methods that extend specified methods
unless the description of the specified method explicitly prohibits
this. Unless there is a specific statement to the contrary, these
extending methods must return whatever value was returned by the call
to call-next-method."

So, something like:

(defvar *class-name-foo-calls* 0)

(defmethod class-name ((class (eql (find-class 'foo))))
   (incf *class-name-foo-calls*)
   (call-next-method))

seems to be something that a portable program can reliably do; I'm
not sure that either of our examples qualify, and suspect that 
some other aspects of class (re)definition could break if standard
class reader methods are "overridden" (rather than "extended").

We'd probably both agree that anyone who does something like:

(defmethod class-direct-superclasses ((class (eql (find-class 'pathological))))
   17)

deserves whatever happens, and we can only hope that whatever happens
happens at fairly high safety.  I can't see any more reason to be concerned
about the effects of a non-extending specialization of CLASS-NAME: even
if a case like your example is probably relatively benign, it's just "not
what CLASS-NAME is supposed to do."