[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.