clamen@CS.CMU.EDU (Stewart Clamen) (05/16/91)
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? -- Stewart M. Clamen Internet: clamen@cs.cmu.edu School of Computer Science UUCP: uunet!"clamen@cs.cmu.edu" Carnegie Mellon University Phone: +1 412 268 3620 Pittsburgh, PA 15213-3890, USA Fax: +1 412 268 1793
Hornig@RIVERSIDE.SCRC.SYMBOLICS.COM (Charles Hornig) (05/16/91)
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.Gregor@parc.xerox.com (Gregor Kiczales) (05/16/91)
There are several published papers which discuss how to do this. Among them is "Efficient Method Dispatch in PCL," by myself and Luis Rodriguez. This paper appeared in the proceedings of the 1990 Lisp and Functional Programming Conference. The mechanism described in the paper is implemented in PCL, which is publicly available. The short answer to the question is that most existing implementations do not update all the instances as soon as the class is defined. Instead, they do something like arrange for the next cache access (slot lookup or generic function call) for that instance to miss. The required update is detected and handled as part of the miss handler.
jonl%kuwait@LUCID.COM (Jon L White) (05/17/91)
re: The short answer to the question is that most existing implementations
do not update all the instances as soon as the class is defined.
I'm curious. Although we've carefully crafted the CLOS design so that
it is permissible to do the updates "eagerly", does anyone know of ANY
CLOS implementation, either in use or planned, which does not do the
explicit version check upon access? [and "explicit check" also covers
the case of overloading "cache misses" for this purpose, to reduce
the overhead of access.]
Lucid's implementation has some extensions beyond the CLOS spec for
eagerly caching up all the method combinations and other tricks that might
be needed for generic functions, which would otherwise just be lazily
computed in the same way that macro-expansions in the interpreter are
*usually* delayed until necessary. It wouldn't take much more to provide
an explicit inteface for assuring that all objects are "up to date".
How important would this be to anyone? We've assumed that these
extensions are for those who either want a stripped-down delivery system
(one,say, in which there will be no further redefinitions, so the
redefinition and update code can just be "shaken" out of the image).
But in fact the more common usage seems to be to "warm up" all the caches
so that some demonstration of the WhizzySoftwareSystem won't be interrupted
by odd, "on the fly" pauses while caches fill up and garbage is collected.
-- JonL --