mop questions

[davis@ilog.ilog.fr]

Gregor and Jim,

Thanks for your prompt replies.  There are a couple of issues I wanted
to ask about in some more depth.

      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.

The reason I ask these questions, of course, is in the context of
EuLisp and TELOS.  In EuLisp we would like function bindings - and
especially important ones like slot accessors - to be defined entities
known to the compiler.  There is also a large interest in factoring
complex behavior like that provided by DEFCLASS into a composition of
simpler but well-specified behaviors.  Adding defining forms for these
rather special functions seems like a natural way to achieve these
goals.  So what I'd like to know primarily is if you think this is a
reasonable approach.  In particular, I'm not interested in challenging
CLOS's decisions, just in figuring out the best way for EuLisp.

Also in EuLisp class redefinition is not such an important issue.  The
interactive case is seen as special, and special processing rules can
apply.  What we are largely concerned with (at least on this side of
the Channel) is module compilation.

      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 apologize for this question.  I made some bad assumptions based on
some slightly obscure language in 88-002R page 2-28 and a stronger
TELOS restriction on generic functions.  In the CLOS specification,
"The :method-class option is used to specify that all methods on this
generic function are to have a different class from the default
provided by the system..."  I assumed that all methods on a generic
function were intended to have the same class.  This is a useful
restriction for certain purposes, and it is embodied in TELOS.  (The
abstraction point is a good one and argues against the restriction.)
However, I see in the latest MOP pages 3-74 to 3-76 language which
implies that this is not in fact a CLOS restriction.  Anyway, assuming
the restriction, it makes sense to think about reader and writer
generic functions, and not just reader and writer methods.  The
existence of METHOD-SLOT-NAME then prompted me to wonder if you
intended it to be an error to have different methods on such a generic
function access different slots.  In fact, I found it unusual that
there would be such an error, thus the question.

      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.

What issues are you thinking about here?  These questions about slot
definition metaobjects are particularly interesting to me, since it is
one of the areas in which TELOS differs the most from CLOS.

      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.

The version of the AMOP that I have does not discuss slot definition
metaobjects.

   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.

So do you see a class as having only one kind of slot definition for
all of its slots?  One of the goals of the TELOS MOP was the ability
to mix-n-match slot definition metaobjects of different classes within
the same class metaobject.  I think this is only a partial success in
the current version; the EuLisp community is working on refinements as
I write.


Thanks again for your thoughtful (dare I say `reflective'?) answers.

-- Harley

PS I received two copies of each of your messages, as well as a
message from the PARC postmaster with the following error:

  A copy of your message is being returned to you because one or more of
  the addresses you specified could not be recognized as addresses that are
  understood by, or reachable from, this system.
  
  error: err.unresolvable: nori@kagaku.se.fujitsu.co.jp.ARPA
  error: err.unresolvable: jac@computer-lab.cambridge.ac.uk.ARPA
  error: err.unresolvable: ida@cc.aoyama.ac.jp.ARPA
  error: err.unresolvable: harlqn.mop@harlqn.co.uk.ARPA