Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!spool.mu.edu!uwm.edu!bionet!agate!ucbvax!tut.cis.ohio-state.edu!unreplyable!garbage From: Hornig@RIVERSIDE.SCRC.SYMBOLICS.COM (Charles Hornig) Newsgroups: comp.lang.clos Subject: Redefining Classes in CLOS Message-ID: <19910516125104.2.HORNIG@MR-WIZARD.SCRC.Symbolics.COM> Date: 16 May 91 12:51:00 GMT References: Sender: welch@tut.cis.ohio-state.edu Distribution: inet Organization: CommonLoops Lines: 38 Date: Wed, 15 May 1991 22:37 EDT From: clamen@O.GP.CS.CMU.EDU (Stewart Clamen) Section 28.1.10 in the 2nd Edition of CLtL features the following: A class that is in an instance of STANDARD-CLASS can be redefined if the new class will also be an instance of STANDARD-CLASS. Redefining a class modifies the existing class object to reflect the new class definition; it does not create a new class object for the class. [rest of paragraph omitted -- SMC] When the class C is redefined, changes are propogated to its instances and to instances of any of its subclasses. Updating such an instance occurs at an implementation-dependent time, but no later than the next time a slot of that instance is read or written. Updating an instance does not change its indentity as defined by the EQ function. The updating process may change the slots of that particular instance, but it does not create a new instance. Whether updating an instance comsumes storage is implementation-dependent. ... I am curious as to how the current implementations of CLOS (both commercial and research) attempt to conform to this specification. Is this feature generally supported yet? Do implementations that do support it convert all instances at the time of class redefinition, or "lazily"? Are there limitations on the types of changes that can be made to a class? Symbolics' (commercial) CLOS conforms to this specification. We convert the instances "lazily". There are no limitations.