[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compilation implications
- To: kempf@Sun.COM
- Subject: Re: Compilation implications
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 3 Jan 89 12:56 EST
- Cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM
- In-reply-to: <8901031731.AA11579@suntana.sun.com>
Date: Tue, 03 Jan 89 09:31:00 PST
From: kempf@Sun.COM
>packages just as a consistency check. Unfortunately, I don't see how
>to evaluate the myriads of consistency checks that could conceivable be
>placed in a "dumped" class; would they be worth the effort?
The class redefinition protocol is probably the right way to go here.
If there is a difference between the instance structure in the file
and in memory, it could be called to update the instance.
I thought you said you agreed with my proposal that the way to load an
instance of a standard-class from a compiled file is for a method of the
instance to return a form which is then evaluated at load time. Once
this is adopted, there is no such thing as "the instance structure in
the file" and no issue of making that structure consistent with some
other structure. The semantics of loading an instance of a standard-class
from a compiled file can be entirely understood in terms of MAKE-INSTANCE
or whatever other function is called by the form returned by MAKE-LOAD-FORM;
no new concepts need be introduced. If the programmer of a given class
wants to use the class redefinition protocol, that class's MAKE-LOAD-FORM
method can output something that uses that protocol, and if he doesn't,
it can output something that doesn't.