Re: CLOS defining macros & compilation

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Thu, 23 Feb 89 15:16:58 PST
> From: kempf@Sun.COM
> 
> This is going to put a crimp in the usual style of OO programming, namely
> to define classes at the top of a file, then the methods applicable to
> them thereafter. What you're saying is that this style would be
> potentially nonportable.

That certainly isn't my intent -- I want to legitimize current
programming practice while glossing over the details of how it's
actually implemented.

I can't find any reference in 88-002R to whether classes named as
parameter specializers in a DEFMETHOD must be defined before the
DEFMETHOD is "evaluated", much less in advance of when the DEFMETHOD
is macroexpanded.  (It says a parameter specializer is a symbol that
names a class.) The MOP document does seem to imply that there must be
real class objects defined at compile time, but only so it can create
a real method object at compile time.  We could put in an explicit
statement that classes that appear as DEFMETHOD's parameter
specializers must be known at compile time and that compiling a
DEFCLASS will make the class name known to the compiler for this
purpose.  We probably need to say something similar about class names
defined by DEFSTRUCT as well, right? 

We could also put in a statement that DEFCLASS makes the class name
known to the compiler so it can appear as a superclass in another
DEFCLASS, analogous to the language about the DEFSTRUCT :INCLUDE
option in proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.  But
88-002R already says that superclasses don't need to be defined at all
if the metaclass is STANDARD-CLASS, so this might be unnecessary. 

-Sandra
-------