[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CLOS questions



I have still more questions, this time about chapters 1 and 2.


Page 1-15 of 88-002R says that 

  "Each class that corresponds to a predefined Common Lisp type
  specifier can be implemented in one of three ways ...  a standard
  class ..., a structure class ..., or a built-in class ..."

Shouldn't this also permit the possibility of other
implementation-specific metaclasses?  For example, in our current
implementation the class PATHNAME is an instance of metaclass
FLAVOR-CLASS.


Page 1-27 says that the default argument precedence order is left to
right, but I wonder if in the case of (SETF ...) functions it wouldn't
make more sense for the default order to put the new-value argument last
instead of first?  This wouldn't normally change the semantics, but it
could affect efficiency.


I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
generic functions with a primary method on class STANDARD-OBJECT which
just invokes a SLOT-...-USING-CLASS generic function.  Do these really
need to be generic at both levels?  According to the specification,
SLOT-BOUNDP, for example, should be implemented as

  (defgeneric slot-boundp (instance slot-name))
  (defmethod slot-boundp ((instance STANDARD-OBJECT) slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

but it seems like it would make more sense to do either 

  (defgeneric slot-boundp (instance slot-name))
  (defmethod slot-boundp ((instance T) slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

or just
  
  (DEFUN slot-boundp (instance slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

Note that the latter parallels the way that SLOT-VALUE is specified.


The syntax template for WITH-ADDED-METHODS [p. 2-90] differs from
GENERIC-LABELS [p. 2-55] by defining exactly one function instead of an
arbitrary number of functions.  This is not mentioned anywhere in the
text, which makes me wonder if that is intentional or if it might be just
a typographical error?


For functions INVALID-METHOD-ERROR and and METHOD-COMBINATION-ERROR to
be fully portable, it would be helpful to have some sort of guideline on
message formats.  For example, should it be a phrase, or a complete
sentence?  Otherwise, a message that looks elegant on one implementation
could look bad on another because it is displayed in a different
context.


Page 2-19 should be updated to show COMPUTE-APPLICABLE-METHODS being a
generic function to match page 3-38.


Is someone planning to specify exactly which conditions are supposed to be
signalled for the various "signals an error" situations?


What package are these symbols in?  Also, given the emphasis on having
the standard package contain exactly the standard set of symbols, it
would be helpful to have an official list of the exported CLOS symbols.
For example, I had trouble deciding whether STANDARD was supposed to be
a defined symbol [until I found the reference on page 1-31].