> re: Does a MOP user really know the names of the slot where initforms and
  >     initfunctions are stored?
  > 
  > No.

All definitions im AMOP are method-based; this gives a purely
functional interface, which abstracts from a concrete implementation
of CLOS. This idea was so good that it has even found its way into the
non-LISP community (e.g. into the ODMG specification on o-o
databases or into Java Beans).

IMHO, one minor drawback in AMOP are the keyword arguments: This is
the only place where the quite abstract definitions in AMOP meet quite
closely an (imaginary) implementation of CLOS.

  > CLOS:SLOT-DEFINITION-INITFORM is the documented way to access the
  > :initform information . . . (but I forget whether there is a
  > standard requirement that it be SETF'able too;)

It will surely be not defined as SETF'able in AMOP, since this would
mean to allow some destructive side effects and modifications to a
running CLOS. AMOP takes care to define only `constructive' changes to
CLOS, that means for example, changes done by the metaobject
programmer when creating metaobjects. But as Jon stated already, using
some destructive proceeding is sometimes easier to use ...

Allowing destructive changes are totally left to the CLOS' provider,
since this influences the overall performance of the concrete
implementation. For example, a CLOS implementation could decide on
doing slot access optimizations after the class metaobject has
finalized its inheritance (and LW and ACL do so, in fact); allowing
destructive changes to metaobjects could either have no effect at all
or could even make the system instable.
-- 
Viele Gruesse, Heiko