[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initialize-instance on an exisiting instance
Date: 19 Oct 87 09:01 PDT From: Danny Bobrow
<Bobrow.pa@Xerox.COM>
We did not discuss this, but if a user calls
initialize-instance
on an existing instance, it seems that it should work.
This would be a way of reinitializing an instance. Is there
any problem with this? I would rather this be true than say
"it is an error" to initialize an instance more than once.
Given what we said about permissible optimizations in
initialize-instance, I don't see how the semantics of this
operation could be well-defined, unless this isn't really the same
initialize-instance that make-instance calls. That might be
reasonable: change "permissible optimizations in
initialize-instance" to "permissible optimizations in
initialize-instance when called by make-instance."
Either what I am asking makes sense, and it must be "permissible
optimizations in initialize-instance when called by make-instance.", or
what I am saying is nonsense, and the only place initialize-instance can
be called is make-instance, in which case "permissible optimizations in
initialize-instance" is the same as "permissible optimizations in
initialize-instance when called by make-instance."
However, I'm not sure that calling initialize-instance on an
existing instance is going to be a particularly useful operation.
Does it first reset all the slots to uninitialized? Regular
initialize-instance doesn't do that. What if there are
user-defined initialize-instance methods that do such things as
adding the instance to an auxiliary data structure? Can they
tolerate adding it twice? Or should one call a new function
deinitialize-instance before calling initialize-instance?
I think users who cause side effects in initialization should be aware
of them. But otherwise one would want the effect to be as though you
had just allocated a new instance, except that one has an instance eq to
the original. We have had some Loops users who have used a feature
like this. But the problems you mention are real, and it was why I sent
out my query.
Perhaps, a simpler way of providing for this purpose would be to provide
a generic-function (copy-slot-contents from to) whose default behavior
for instances of the same class is to copy the contents (incuding
unbound slots). Or should this be only a function that signals an error
when the classes of the two instances are not the same? Or is this too
esoteric an application to be included in the standard. In any event,
we must make a statement about initialize-instance, and how many times
it can be called (and from where?).