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



Reference: X3J13/92-102, dpANS 12.24




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.


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:


(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


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



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:



Eliminating the need for an awkward idiom is an improvement.


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.