🚀 go-pugleaf

   Date:	Fri, 10 Apr 1992 08:19:14 -0700
   From:	Jeff Dalton <jeff@aiai.edinburgh.ac.uk>

   Is it really the only reason?  It's certainly not the only thing
   SLOT-VALUE is used for.

Yes, I probably overstated this case before.  You aren't the first
person who has caught me on it.  I think the other reasons you mention
are, in and of themselves, good reasons to have SLOT-VALUE in the
language.  All I really wanted to say is that its important for accessor
methods to go through SLOT-VALUE so that methods on
SLOT-VALUE-USING-CLASS will be called.

   You can do an optimization, but don't you have to be able to
   de-optimize if someone later defines an applicable method on
   SLOT-VALUE-USING-CLASS?

This depends on whether you are supporting a development environment or
a delivery environment.  The text in the AMOP tries to help implementors
out by letting them off this hook for delivery environments.  Page 144
says: 

 \item Portable methods on specified generic functions specialized to portable
 metaobject classes must be defined before any instances of those classes (or
 any subclasses) are created, either directly or indirectly by a call to {\bf
 make-instance}.  Methods can be defined after instances are created by {\bf
 allocate-instance} however.  Portable metaobject classes cannot be redefined.

 \begin{ImplNote}
 The purpose of this last restriction is to permit implementations to provide
 performance optimizations by analyzing, at the time the first instance of a
 metaobject class is initialized, what portable methods will be applicable to
 it.  This can make it possible to optimize calls to those specified generic
 functions which would have no applicable portable methods.
 \end{ImplNote}