#

## Issue METHOD-INITFORM Writeup

    Date: Fri, 8 Jun 90 20:00 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: Issue: METHOD-INITFORM (Version 5)
    To: X3J13@mcc.com
    Message-ID: <19900609000021.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

    This version contains the corrections to current practice noted at
    the X3J13 meeting today.

    METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD failed 0-11
    METHOD-INITFORM:FORBID-CALL-NEXT-METHOD passed 13-0

    Issue:         METHOD-INITFORM

    References:    88-002R p.2-12

    Category:      CLARIFICATION

    Edit history:  29-Apr-90, Version 1 by Moon
                   30-Apr-90, Version 2 by Moon (update current practice)
                   4-May-90, Version 3 by Moon (update discussion and current
                                                practice)
                   5-Jun-90, Version 4 by Moon (update current practice)
                   8-Jun-90, Version 5 by Moon (update current practice)

    Problem description:

      Should CALL-NEXT-METHOD and NEXT-METHOD-P be allowed in initforms for
      optional and keyword parameters and &AUX variables of methods?  The
      document currently allows them only in the body of a method, not in forms
      embedded in the lambda-list, although it takes a close reading of the
      document to discern this.

      There are two proposals in this issue.

      This is Symbolics issue #15.

    Proposal (METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD):

      Expand the lexical scope of CALL-NEXT-METHOD and NEXT-METHOD-P to include
      all forms in a method, including forms embedded in the lambda-list.

    Rationale:

      This seems more natural and consistent.

    Proposal (METHOD-INITFORM:FORBID-CALL-NEXT-METHOD):

      The lexical scope of CALL-NEXT-METHOD and NEXT-METHOD-P includes only
      forms in the body of a method.

    Rationale:

      This is the status quo and is easier to implement.

    Examples:

      (defmethod foo ((x myclass) &aux (y (call-next-method)))
        (if (null y)
            (zzz)
            (list ':baz y)))
      ;is briefer than
      (defmethod foo ((x myclass))
        (let ((y (call-next-method)))
          (if (null y)
              (zzz)
              (list ':baz y))))

      (defmethod countem ((x myclass) &optional (local (not (next-method-p))))
        (let ((accum (if local 0 (call-next-method))))
          (dolist (y (frobs x))
            (incf accum y))
          accum))
      ;is briefer than
      (defmethod countem ((x myclass) &optional (local nil local-p))
        (let ((accum (if (if local-p local (not (next-method-p)))
                         0 (call-next-method))))
          (dolist (y (frobs x))
            (incf accum y))
          accum))

      (defmethod jack-of-confusion ((x myclass))
         (defmethod ace-of-confusion ((x myclass)
                                      &optional (y (call-next-method)))
           (borf x y))
         (ace-of-confusion x))
      ;In METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, the default value for y
      ;is the value returned by an ace-of-confusion method.
      ;In METHOD-INITFORM:FORBID-CALL-NEXT-METHOD, the default value for y
      ;is the value returned by a jack-of-confusion method.

    Current practice:

      Symbolics Genera 8.0, Lucid 4.0.0 Beta-1, and recent versions of
      PCL appear to implement METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD.
      TI Explorer release 6 does not.
      Apple and IIM implement METHOD-INITFORM:FORBID-CALL-NEXT-METHOD.

      The first example does not actually work in Genera due to a bug.

      Other CLOS implementations were not surveyed.

    Cost to Implementors:

      In METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, handling CALL-NEXT-METHOD and
      NEXT-METHOD-P by simply wrapping a FLET or MACROLET around the body will
      not work.  If they are called from forms in the lambda-list some
      massaging of the lambda-list is necessary.  It's not very difficult,
      though.

      METHOD-INITFORM:FORBID-CALL-NEXT-METHOD has no cost to implementors.

    Cost to Users:

      None for either proposal.

    Cost of non-adoption:

      METHOD-INITFORM:FORBID-CALL-NEXT-METHOD forbids a programming technique
      that users might find useful.  METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD
      requires a little more work for implementors, who might have thought
      they had finished their CLOS implementations by now.

    Performance impact:

      None.

    Benefits:

      METHOD-INITFORM:FORBID-CALL-NEXT-METHOD avoids changing the status quo.
      METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD provides a programming technique
      that users might find useful.

    Esthetics:

      METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD seems more uniform.

    Discussion:

      Jeff Dalton suggests that the places where CALL-NEXT-METHOD is allowed
      should be consistent with the places where RETURN from an implicit block
      is allowed.  This probably supports FORBID-CALL-NEXT-METHOD.

      Gregor Kiczales says he supports FORBID-CALL-NEXT-METHOD, but is not
      adamant about it.  He thinks FORBID-CALL-NEXT-METHOD is more natural.

Copyright 1996-2001, Xanalys Inc. All rights reserved.