Re: mop questions

[Gregor Kiczales <gregor@parc.xerox.com>]

Thanks for your comments on the AMOP.  As Jim has addressed most of them
in his previous message, I will focus on your MOP comments.  You can
also expect that we will get back to you with questions about your AMOP
comments in the coming weeks.

   Date: 	Tue, 30 Oct 1990 09:02:17 PST
   From: davis@ilog.ilog.fr

   1. Why does DEFCLASS expand into ENSURE-CLASS instead of
   MAKE-INSTANCE?  (Ditto for other defining macros.)

There is an important layer of functionality between them that needs to
be captured.  (MAKE-INSTANCE creates and deals with anonymous
metaobjects.  DEFCLASS provides a nice syntax for creating/redefining
named metaobjects.  ENSURE-CLASS provide the naming functionality.
Specifically, if there is no class with this name, create one
(make-instance) otherwise reinitialize the existing one
(reinitialize-instance).

   2. Why are slot readers/writers/accessors created and bound inside of
   INITIALIZE-INSTANCE instead of in their own defining forms (eg
   DEFREADER, DEFACCESSOR, etc.)?

I don't know what this means.  CLOS doesn't have forms like DEFREADER.
It could of course, but doesn't.  In addition, CLOS requires
redefinition of class with different accessors, readers or writers to
remove the old ones and add the new ones.

If, as you may be suggesting, DEFCLASS converted readers and writers to
DEFREADER and DEFWRITER, it would require that defclass did all the work
of keeping track of new and old definitions.  This doesn't fit the
conceptual model we are trying to use that the state of class definition
is entirely in the metaobject.  It would also prevent the functionality
of readers and writers from being available in classes created
anonymously by MAKE-INSTANCE.

   3. When Danny was here some months ago, he mentioned the possibility
   of reifying specializers into "specializer metaobjects".  Was anything
   more written or discussed about this?  There seem to be hooks in the
   MOP, and one brief footnote in AMOP, but no explicit discussion.

We should have done this, but there is language in chapters 1 and 2 of
the CLOS spec which suggests that an eql specializer is a list of the
form (EQL <object>).  In order to conform to that, and because making
specializers full-on objects introduces added complexity, we haven't
done it.  But, we could be pushed I suppose.

   4. Why does the function GENERIC-FUNCTION-NAME exist, aside from
   debugging?

Same reason as CLASS-NAME.  Debugging, browsing, inspecting.

   5. Is CLOS supposed to detect when new methods are added to reader or
   writer generic functions, when those new methods do not access the
   same slot as the original generic function?  This question arises from
   the existence of the function METHOD-SLOT-NAME.

I don't understand this question.  When you add a new method to a
generic function, you just add it.  Whether the generic function
previously had only automatically created reader or writer methods
doesn't enter into it.  There is no reason why two automatically
generated readers methods, on the same generic function, can't read
slots with different names.

I think about this by viewing generic functions and slots as being at
different layers of abstraction.  What slot a given generic function
happens to read is a secret---only the implementor of the relevant
method knows.  So, if two methods happen to read slots with different
names, so what.  The job of the generic function is to access certain
information, and the job of the person who writes the method is to know
how that maps onto slots of the instance.

   6. Do you intend there to be any sort of correspondence between slot
   allocation as given by the :ALLOCATION slot option and the class of
   the slot definition metaobject?  I don't think so, but is this at
   least a viable implementation approach?

The MOP doesn't do this.  It treats allocation as state associated with
the slot definition metaobject rather than as determining the class of
the slot definition metaobject.  We could have done it differently, but
the currents scheme works pretty well for now.

Going the other way also gets too quickly into unresolved issues about
programming with dynamically created classes.

   7. Would the intended CLOS way to implement, for example, slot facets
   be with new class metaobjects as we see in section 3.3 of AMOP, or by
   defining new slot definition metaobject classes?  If the answer is the
   former, what would be a good reason to do the latter?

The AMOP does this by defining both a new class metaobject class and a
new slot definition metaobject class.  Conceptually, the new class of
slot definition metaobject is to say "it's OK to have an allocation you
haven't seen before."  The new class of class metaobject is to say "here
is a kind of class which implements its instances as having these new
kinds of slots."  So, both are needed, they serve complementary roles.

You could of course imagine a different protocol.