Moon's comments on Draft 11

[Jon L White <jonl@lucid.COM>]

re:  One is to make
    STANDARD-ACCESSOR-METHOD a direct subclass of METHOD instead of a direct
    subclass of STANDARD-METHOD; the other is to make a new class that is a
    direct superclass of both STANDARD-METHOD and STANDARD-ACCESSOR-METHOD.
    I support the former because it's simpler and I can't see a reason for
    the latter, but I would certainly accept the latter if there is a reason
    for it, for example if there is common behavior between the default
    method class used by DEFMETHOD and the default method class used by
    DEFCLASS that should be captured on a common superclass.  We can't make

Wait a minute -- isn't the default class used for DEFMETHOD the class 
in GENERIC-FUNCTION-METHOD-CLASS?  (and the default for the corresponding
argument to DEFGENERIC is STANDARD-METHOD class.)  I liked Scott's idea
of having a way to say to DEFMETHOD that you want it to make a method
of a non-default class; Gregor seemd to support that too.

As to whether the method class for accessor methods should NOT be a
subclass of STANDARD-METHOD -- well, those accessor methods, as objects,
certainly share a awful lot with STANDARD-METHOD's, with only a delta's 
worth of difference.  That's the classic case for subclassing in order 
to maximize code reusability. 

Consider, for a moment, the task that an end user would have if he were 
to define a new method class; it would be very hard for him to do it 
without recourse to subclassing STANDARD-METHOD -- *almost* as hard as 
it would be to correctly define a new metaclass that isn't a subclass 
of STANDARD-CLASS.  This isn't to say that it's a stumbling block for
implementors, but rather to point out the value of code and class
reusability.  So I'd want to see very good semantic (or typological,
or theological) reason before giving up on the commonality.


-- JonL --