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


Issue CHANGE-CLASS-INITARGS Writeup

Issue:          CHANGE-CLASS-INITARGS

Reference: X3J13/92-102, dpANS 12.24

CHANGE-CLASS (p.7-38)

UPDATE-INSTANCE-FOR-DIFFERENT-CLASS (p.7-34)

MAKE-INSTANCE (p.7-50)

Section 7.1.2 Declaring the Validity of Initialization

Arguments (p.7.2)

Section 7.2.2 Initializing Newly Added Local Slots (p.7-9)

X3J13/92-2513, Kim Barrett comment #13

AMOP (p.33, p.310)

Category: Change

Edit History: Version 1, 8/31/91, Kim Barrett

Version 2, 9/6/91, Kim Barrett (Moon's comments)

Version 3, 1/7/93, Kim Barrett (update references)

Status: Proposal PERMIT passed 7-1, March 1993

Problem Description:

Because CHANGE-CLASS does not accept initargs, certain kinds of instance

updates must now go through a two-step process of first calling CHANGE-CLASS

and then calling REINITIALIZE-INSTANCE. If CHANGE-CLASS accepted initargs,

the explicit reinitialization step would be unnecessary.

Proposal (CHANGE-CLASS-INITARGS:PERMIT):

1. Change the syntax for CHANGE-CLASS to

CHANGE-CLASS instance new-class &key &allow-other-keys

and modify the two method signatures currently specified accordingly:

CHANGE-CLASS

(instance standard-object) (new-class standard-class) &rest initargs

CHANGE-CLASS (instance t) (new-class symbol) &rest initargs

with the initargs parameter described in the same way as the corresponding

parameter to UPDATE-INSTANCE-FOR-DIFFERENT-CLASS.

2. Change the last paragraph of the description of CHANGE-CLASS to include

the initargs in the arguments passed to the reinvocation, by adding the

phrase "and the \param{initargs}" to the end of the last sentence.

3. Change the description of the process by which newly added local slots are

initialized to specify that CHANGE-CLASS also passes the initargs to

UPDATE-INSTANCE-FOR-DIFFERENT-CLASS. This involves adding mention of the

initargs to the 2nd paragraph of "Initializing Newly Added Local Slots" and

striking the 3rd paragraph.

Editorial Impact:

Several small changes to one function description and one small concept

section.

Rationale:

Makes CHANGE-CLASS more consistant with other parts of the various

initialization protocols, and removes the need for a somewhat awkward idiom.

Current Practice:

Lucid 4.0 and Apple MCL 2.0p2 appear to follow the current specification,

with CHANGE-CLASS not accepting initargs.

Chestnut's Lisp-to-C translator contains a compile-time switch that permits

the user to select whether CHANGE-CLASS accepts initargs or not.

Cost to Implementors:

The generic function definition and any methods on CHANGE-CLASS would need to

be changed to deal with the initargs. Implementors might want to change some

places that might currently call CHANGE-CLASS followed by

REINITIALIZE-INSTANCE to just call CHANGE-CLASS with initargs, and this might

require some other changes as well. The number of occurances of CHANGE-CLASS

is likely small, so it probably isn't too difficult.

Cost to Users:

Similar to the cost to implementors. However, users of multiple

implementations will also have to deal with the different rates at which

vendors incorporate this change.

Performance Impact:

None.

Aesthetics:

Eliminating the need for an awkward idiom is an improvement.

Discussion:

This issue was raised informally some time ago by Gregor and others, but it

appears that no formal proposal was ever made.


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