Various Topics Discussed Last Week

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 28 Sep 87 09:42:29 MST
    From: kempf%hplabsz@hplabs.HP.COM

Comments on excerpts from Jim's message:

    1) On SETF:

    For purposes of finalizing the spec for the November meeting, I think we 
    should drop reference to SETF methods.

I think that would be a mistake, because it would simply be postponing the
problem.  I'd really like to get this stuff finished soon, and I don't think
it's impossibly difficult.  I will mail out a complete proposal for what to
do about SETF later today.

    3) On the object creation proposal:

I agree with most of your comments and will update the draft proposal
accordingly.

    >The primary method for INITIALIZE-INSTANCE is system-supplied...

    Something needs to be said here about the case where a user writes
    a :BEFORE method and SETF's the slot there. From the rest of the text,
    it sounds as if INITIALIZE-INSTANCE is permitted to clobber that slot.

I think that's what we agreed to at the meeting a couple weeks ago.

    This makes :BEFORE methods on INITIALIZE-INSTANCE less then useful
    for slot initialization. The result requires either that INITIALIZE-INSTANCE 
    be singled out in a particular way to prohibit :BEFORE methods, or allows
    the system to arbitrarily clobber something the programmer has done.

I agree with you.

    One way out of this dilemma is to simply have the :BEFORE method and the
    :AROUND method for INITIALIZE-INSTANCE be reserved for the system.
    Similarly for the :AFTER and :AROUND methods of ALLOCATE-INSTANCE. 
    This would leave no places where user defined hooks could be inserted before the
    INITIALIZE-INSTANCE primary is run. Users redefine these qualified methods
    at their own peril, as is the case with redefining any system defined
    method (or function for that matter).

I don't see how the methods could be reserved, since there isn't just one;
there's one for every class.  However, your proposal is essntially the same
as my proposal to have a specialized kind of method combination for these
generic functions, so that user-defined methods would naturally go only where
they made sense.  For some reason that proposal provoked a lot of opposition,
so I dropped it.  It could be revived if there is renewed interest.  In the
meantime, I won't try to put anything about this into the draft object
creation proposal.

    4) On method combination types:

    >An error is signaled if CALL-NEXT-METHOD is used in a primary method. 

    In primaries as well???? If so, then we're talking about a major change,
    because 87-002 allows it in primaries. Or perhaps this is only for the new 
    method combination types? 

Yes, this was in the context of method combination types defined by the short
form of define-method-combination.

			      If so, then I'd be interested in a reason
    for prohibiting method combination in primaries, since it introduces
    a major incompatibility between different types of method combination.

If you can figure out what it would mean for a primary method in that kind
of method combination to call call-next-method, please make a proposal.

    10) On NO-APPLICABLE-METHOD:

    >( no-applicable-method generic-function first-argument &rest
    >all-arguments)

    I thought we had agreed to get rid of the first argument kludge.
    Otherwise, this is the only place in the entire spec where
    we're making a distinction between multiple dispatch object
    oriented programming and classical object oriented programming.
    The user has to go through some additional grief if all the
    arguments are passed as an &REST parameter in order to get
    forwarding, but I think that forwarding should best be left
    to metaobject programmers anyway, since it is, as yet, experimental
    (neither PCL nor New Flavors have it). Someone could write a
    forwarding metaobject method as:

      (defmethod no-applicable-method ( (gf forwarding-generic-function)
					&rest all-arguments
				      )
	 (apply #'forward-method all-arguments)
      )

    A user can do something similar with the default method, with
    somewhat hairier code.

The problem with this is that people want forwarding for "all" generic
functions, not just specially identified ones.  I put "all" in quotation
marks because after they have thought about it deeply they usually discover
that there are some generic functions that mustn't forward.

However, I like your suggestion anyway.  If we make the arguments to
no-applicable-method be generic-function &rest all-arguments, someone
who wants to do delegation can redefine the default method to call
a new generic function with whatever arguments they want.  Not having
that built into CLOS doesn't make it impossible to add on one's own.