no-applicable-method

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

re: 1.  The example that cheeweei has trouble with works fine in my
    system.  At least, the example below works.

    2.  The problem that i have with NO-APPLICABLE-METHOD is that i'd
    really like to specialize it on more than the first argument.  For
    example, say i define a class that uses NO-APPLICABLE-METHOD to do a
    kind of simple delegation:

    (defmethod no-applicable-method ((gf standard-generic-function) &rest args)
	;; Try delegation.
	(let ((method (apply #'find-delegated-method gf args)))
	  (if method (apply method args)
	    (call-next-method))))


I wonder how this example can work since standard methods aren't typically 
implemented as applicable functions.  So  (apply method args)  means ???

A similar problem arose with one of Lucid's end users -- an application
that had a rare case which the person wanted to fix by a similar kind of
delegation.  We've supplied an extension to meet this need, although we'd 
recommend that extensive use of delegation be done in some other way.  The 
design looks something like:

     (defun APPLY-METHOD (method next-methods &rest arguments) ...)

  is a normal function that "dispatches" to the method supplied as it's
  first argument, passing along as arguments the 'arguments' and providing 
  a next-methods context from the argument 'next-methods' ['next-methods' 
  will be a list when "next-methods" are permitted.]

  As to why APPLY-METHOD is not generic -- there is an analogy to SLOT-VALUE.
  The person needing to put methods on it is the "system implementor", and
  he would likely do so on some "meta" level function named something like 
  APPLY-METHOD-USING-CLASS.  Possibly that function would specialize both on 
  the class of the method, and the class of the generic-function that the 
  method "belongs to".  [A method object contains a pointer back to the 
  function that it "belongs to".]  Should the time ever come when it is 
  desirable to do so, we may add APPLY-METHOD-USING-CLASS and "expose" 
  it at the same level as other "meta" things; that way, the end user
  could become a "system implementor" to the degree that the "meta"
  interface allows him.

  APPLY-METHOD-FUNCTION from X3J13/89-003 ["Chapter 3", the metaobject
  proposal that never actually came up to a vote] is much too complex for 
  the user-level need.  Furthermore, it may be presuming too much about the 
  way methods must be implemented.  It requires them to have underlying
  functions -- the METHOD-FUNCTION slot -- but there are some implementations
  with certain classes of efficient methods that don't have such functions.



-- JonL --