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.