The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
invoked explicitly by the user. Under what circumstances would this
capability be useful? (Since it is called directly if a class is
changed via DEFCLASS, I can imagine that if one were mucking with
classes other than via DEFCLASS, one might need to use this function
directly. Is it something like that?)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
> invoked explicitly by the user. Under what circumstances would this
> capability be useful? (Since it is called directly if a class is
> changed via DEFCLASS, I can imagine that if one were mucking with
> classes other than via DEFCLASS, one might need to use this function
> directly. Is it something like that?)
Is it clear that UPDATE-INSTANCE-FOR-REDEFINED-CLASS *doesn't* get
called on instances if you call MIO but *haven't* redefined the class,
in fact?
The only other reason (other than yours, which is probably a good one)
I can think of would be simple because the standard probably needs to
say either that you aren't allowed to call it or that you are, and
it's saying that you are.
Tim Bradshaw wrote:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>
>>The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
>>invoked explicitly by the user. Under what circumstances would this
>>capability be useful? (Since it is called directly if a class is
>>changed via DEFCLASS, I can imagine that if one were mucking with
>>classes other than via DEFCLASS, one might need to use this function
>>directly. Is it something like that?)
>
>
> Is it clear that UPDATE-INSTANCE-FOR-REDEFINED-CLASS *doesn't* get
> called on instances if you call MIO but *haven't* redefined the class,
> in fact?
What about?:
"7.7.20 make-instances-obsolete Standard Generic Function
.....
Description:
The function make-instances-obsolete has the effect of initiating
the process of updating the instances of the class. During updating, the
generic function update-instance-for-redefined-class will be invoked."
Is that in error?
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
··········@tfeb.org (Tim Bradshaw) writes:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
>> invoked explicitly by the user. Under what circumstances would this
>> capability be useful? (Since it is called directly if a class is
>> changed via DEFCLASS, I can imagine that if one were mucking with
>> classes other than via DEFCLASS, one might need to use this function
>> directly. Is it something like that?)
>
> Is it clear that UPDATE-INSTANCE-FOR-REDEFINED-CLASS *doesn't* get
> called on instances if you call MIO but *haven't* redefined the class,
> in fact?
>
> The only other reason (other than yours, which is probably a good one)
> I can think of would be simple because the standard probably needs to
> say either that you aren't allowed to call it or that you are, and
> it's saying that you are.
What do I do if i want to remove a class from a lisp system ? Seems
M-I-O would come into play there.
--
H�kon Alstadheim, hjemmepappa.
······@online.no (H�kon Alstadheim) writes:
> ··········@tfeb.org (Tim Bradshaw) writes:
>
>> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>>> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
>>> invoked explicitly by the user. Under what circumstances would this
>>> capability be useful? (Since it is called directly if a class is
>>> changed via DEFCLASS, I can imagine that if one were mucking with
>>> classes other than via DEFCLASS, one might need to use this function
>>> directly. Is it something like that?)
>>
>> Is it clear that UPDATE-INSTANCE-FOR-REDEFINED-CLASS *doesn't* get
>> called on instances if you call MIO but *haven't* redefined the class,
>> in fact?
>>
>> The only other reason (other than yours, which is probably a good one)
>> I can think of would be simple because the standard probably needs to
>> say either that you aren't allowed to call it or that you are, and
>> it's saying that you are.
>
> What do I do if i want to remove a class from a lisp system ? Seems
> M-I-O would come into play there.
I don't think so, since M-I-O is used when you want an instance of a
class to reflect the new definition of the same class. Leaving aside
the fact that there's no particular way to explicitly remove a class
(that I know of anyway, though I'm sure there's some MOPery that could
do it), if you wanted to stop using a class you'd need to find all the
instances of that class and then use CHANGE-CLASS to make them
instances of some *other* class. Then you just have to track down all
the other references to the class and get rid of them and maybe then
the original class would go away (i.e. be gc'd.) Of course if it
didn't, how could you tell? ;-)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
··········@tfeb.org (Tim Bradshaw) writes:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
>> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
>> invoked explicitly by the user. Under what circumstances would this
>> capability be useful? (Since it is called directly if a class is
>> changed via DEFCLASS, I can imagine that if one were mucking with
>> classes other than via DEFCLASS, one might need to use this function
>> directly. Is it something like that?)
>
> Is it clear that UPDATE-INSTANCE-FOR-REDEFINED-CLASS *doesn't* get
> called on instances if you call MIO but *haven't* redefined the class,
> in fact?
Based on my reading of the spec, I'd say it *does* get called. From
4.3.6 Redefining Classes:
If a class is redefined in such a way that the set of local slots
accessible in an instance of the class is changed, a two-step
process of updating the instances of the class takes place. The
process may be explicitly started by invoking the generic function
make-instances-obsolete.
The two-step process is then defined as first modifying the structure
of the class to (step 1) add and remove slots in accordance with the
new definiton and then (step 2) calling UPDATE-INSTANCE-FOR-REDEFINED-
CLASS.
Since MAKE-INSTANCES-OBSOLETE starts the process and there's nothing
that says anything about aborting the process UPDATE-INSTANCE-FOR-
REDEFINED-CLASS is *not* called in certain circumstances, I'd expect
that after a call to MAKE-INSTANCES-OBSOLETE, UPDATE-INSTANCE-FOR-
REDEFINED-CLASS will be called with the unchanged instance, an empty
list of slots that were added, an empty list of slots that were
discarded and an empty plist of discarded slots and their values.
Which will then call SHARED-INITIALIZE with no initargs (hmmm, that
might explain why the :default-initargs aren't used, as I just asked
about in another thread) which will, thus have no effect on the
object. Presumably an implementation would be justified in optimizing
all that as long as their are no other applicable methods on
UPDATE-INSTANCE-FOR-REDEFINED-CLASS or SHARED-INITIALIZE.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: james anderson
Subject: Re: Calling MAKE-INSTANCES-OBSOLETE directly
Date:
Message-ID: <4058C753.FDB01238@setf.de>
Peter Seibel wrote:
>
> ··········@tfeb.org (Tim Bradshaw) writes:
>
> > Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> >> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
> >> invoked explicitly by the user. Under what circumstances would this
> >> capability be useful? (Since it is called directly if a class is
> >> changed via DEFCLASS, I can imagine that if one were mucking with
> >> classes other than via DEFCLASS, one might need to use this function
> >> directly. Is it something like that?)
one distinction, between make-instances-obsolete and explicit invocation of
update-instance-for-redefined-class, is that m-i-o is specified to initiate
the update process, but there is no requirement that this process complete synchronously.
? (defclass test ()
((s1 :initform 1)))
#<STANDARD-CLASS TEST>
? (defparameter *t1* (make-instance 'test))
*T1*
? (trace update-instance-for-redefined-class)
NIL
? (make-instances-obsolete 'test)
#<STANDARD-CLASS TEST>
? (+ 1 2)
3
? (print *t1*)
Calling (UPDATE-INSTANCE-FOR-REDEFINED-CLASS #<TEST #x81A0816> NIL NIL NIL)
UPDATE-INSTANCE-FOR-REDEFINED-CLASS returned #<TEST #x81A0816>
#<TEST #x81A0816>
#<TEST #x81A0816>
?
which would indicate that, if a given instance is never referenced subsequent
to its obsolence, the update need never happen. in addition, the update is
independent of possible structural changes. think of it as a call to
shared-initialize contingent upon future reference.
...
Peter Seibel <·····@javamonkey.com> writes:
> The CLHS specifically mentions that MAKE-INSTANCES-OBSOLETE may be
> invoked explicitly by the user. Under what circumstances would this
> capability be useful? (Since it is called directly if a class is
> changed via DEFCLASS, I can imagine that if one were mucking with
> classes other than via DEFCLASS, one might need to use this function
One might indeed need to use it for doing MOPpish things that extend
or bypass DEFCLASS in some way. Generally, you'll need to call it,
when a class is changed (by DEFCLASS or other means) in a way that
necessitates updating the instances, but doesn't guarantee it (the set
of local slots didn't change). It's a hook to get the system to run
your UPDATE-INSTANCE-FOR-REDEFINED-CLASS methods, so you can effect
arbitrary changes to all the instances.
--
Pekka P. Pirinen
If it's spam, it's a scam. Don't do business with net abusers.