#

## 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.

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