Why can't DEFMETHOD talk to FORWARD-REFERENCED classes?

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

Can anyone justify the restriction in 88-002R, p.2-24, that
requires "A class must be defined before it can be used as a
parameter specializer in a DEFMETHOD form"?

Several questions have cropped up in the Lucid user community:

  (1) What does "defined" mean?  does it mean fully-defined such
      that an instance can be made? [see the preceeding restriction
      for MAKE-INSTANCE, on p.2-24]  Or, could it be "defined" as
      simply being some forward-referenced class [i.e., no DEFCLASS
      has ever been done for it, but it was mentioned in the super-
      classes list of some other defined class]

  (2) When is a class considered to be "used" in a DEFMETHOD form?  
      Super-eagerly, at the time of macroexpansion of the DEFMETHOD
      form?  Or, eagerly, at the time of evaluation of the DEFMETHOD
      form?  Or, lazyily, at the first invocation of the generic 
      function?   Or, lazily, at the first invocation of that particular
      method?
  
  (3) Is this restriction peculiar to DEFMETHOD, or should it apply
      to ADD-METHOD also?


I'm tempted to think that this restriction was imposed before 
WITH-SLOTS took its present form -- perhaps it was felt that it was
necessary to disambiguate between special-variable references and slot 
"variable" references in method code, such as you might have to do in 
SmallTalk or Flavors.  But this is not the case in CLOS; and if this 
is the only reason for such a restriction, then it is overly burdening 
the user community.

Incidentally, if *any* reasoning about the slots structure of the
specialized class is behind this restriction, then the answer to
the first question above must be "fully-defined", since inherited
slots contribute to a class's slots structure.



-- JonL --