CLOS questions

[Patrick Dussud <dussud@lucid.com>]

   Sender: GRAY@Kelvin.csc.ti.com
   Date: Thu, 16 Feb 89  15:31:03 CST
   From: David N Gray <Gray@DSG.csc.ti.com>


   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.

There is a compatibility question that needs to be answered. Right now,
pathname is not supposed to be a class, so the question is mute, but when it
will be, its metaclass has to be compatible with standard-class, so a portable
program can inherit from it, and specialize some methods on it, as if it were a
standard-class instance. 

   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.

Maybe it does affect efficiency in some implementations, but I don't think it
has to.  I think that the user would be confused if we establish different
default rules for setf generic functions. I except user changing the default
procedence order if they know that the value is not significant for
discrimination.

   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
   Note that the latter parallels the way that SLOT-VALUE is specified.

I think we said that was a bug. They all should be functions like slot-value.