This is a multi-part message in MIME format.
--------------A1888646AD53977C91A95B6A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
Suppose I defined a class with DEFCLASS.
Then I created some instances of this class with
MAKE-INSTANCE. Some time later I decide to remove
a slot from created class.
Would you mind tell me the sequence of actions in such
situation or where I can read about that.
Probably all instances should be recreated. Is this true ?
After that I should perform all additional modifications
which were made after when I've created instances the first time.
Such situation seems to be common. So I supposed that
specific technique is exists.
Thanks.
--
Vladimir Zolotych ······@eurocom.od.ua
--------------A1888646AD53977C91A95B6A
Content-Type: text/x-vcard; charset=us-ascii;
name="gsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vladimir V. Zolotych
Content-Disposition: attachment;
filename="gsmith.vcf"
begin:vcard
n:Zolotych;Valdimir V.
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
·····················@eurocom.od.ua
x-mozilla-cpt:;0
fn:Valdimir V. Zolotych
end:vcard
--------------A1888646AD53977C91A95B6A--
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> Suppose I defined a class with DEFCLASS.
> Then I created some instances of this class with
> MAKE-INSTANCE. Some time later I decide to remove
> a slot from created class. [...]
> Probably all instances should be recreated. Is this true ?
> After that I should perform all additional modifications
> which were made after when I've created instances the first time.
No, as long as you update the methods to not require use of the slot,
you don't have to recreate the instances. They'll be adjusted
appropriately for you by magic. If you've renamed a slot, such that
you need to make a new slot value dependent on a going-away slot value,
there's a way to do that, too, but it doesn't happen automatically;
you have to write some code. See the Objects chapter of the HyperSpec.
In article <·················@eurocom.od.ua>, "Vladimir V. Zolotych"
<······@eurocom.od.ua> wrote:
> Hello,
>
> Suppose I defined a class with DEFCLASS.
> Then I created some instances of this class with
> MAKE-INSTANCE. Some time later I decide to remove
> a slot from created class.
>
> Would you mind tell me the sequence of actions in such
> situation or where I can read about that.
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/stagenfun_upd_efined-class.html
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig wrote:
> In article <·················@eurocom.od.ua>, "Vladimir V. Zolotych"
> <······@eurocom.od.ua> wrote:
>
>> Hello,
>>
>> Suppose I defined a class with DEFCLASS.
>> Then I created some instances of this class with
>> MAKE-INSTANCE. Some time later I decide to remove
>> a slot from created class.
>>
>> Would you mind tell me the sequence of actions in such
>> situation or where I can read about that.
>
>
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/stagenfun_upd_efined-class.html
Yes thats nice and useful - but another critical part that I miss in CLISP.
I think it would be interesting why they have chosen to not implement
things like "update-instance-for-redefined-class" or
"update-instance-for-different-class". I think they want to gain speed and
free-memory by not maintaining instance-tables.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>
> Rainer Joswig wrote:
>
> > In article <·················@eurocom.od.ua>, "Vladimir V. Zolotych"
> > <······@eurocom.od.ua> wrote:
> >
> >> Hello,
> >>
> >> Suppose I defined a class with DEFCLASS.
> >> Then I created some instances of this class with
> >> MAKE-INSTANCE. Some time later I decide to remove
> >> a slot from created class.
> >>
> >> Would you mind tell me the sequence of actions in such
> >> situation or where I can read about that.
> >
> >
> http://www.xanalys.com/software_tools/reference/HyperSpec/Body/stagenfun_upd_efined-class.html
>
> Yes thats nice and useful - but another critical part that I miss in CLISP.
> I think it would be interesting why they have chosen to not implement
> things like "update-instance-for-redefined-class" or
> "update-instance-for-different-class". I think they want to gain speed and
> free-memory by not maintaining instance-tables.
If I recall correctly (it's been a long time since I looked at the
implementation level of one of these) the price in speed is already paid
if you do multiple inheritance. You still have to accomodate that slots might
"move" due to incompatible otherwise-fixed positions in parent classes.
Given that you have to "detect" this, i.e., dispatch on the class to find the
true loc of the slot anyway, I seem to recall there's an implementation
technique whereby at no cost you can detect old instances and know to update
them on any use... Maybe I'm misremembering some of the details, but that's
all that's left in my brain on this. Someone else can probably elaborate.
In any case, it's possible that some particular implementation worked them
into a performance corner, but it's unlikely that speed and correctness are
really in conflict here.
Kent M Pitman <······@world.std.com> writes:
[CLISP and missing support for update-instance-for-*]
> If I recall correctly (it's been a long time since I looked at the
> implementation level of one of these) the price in speed is already paid
> if you do multiple inheritance. You still have to accomodate that slots might
> "move" due to incompatible otherwise-fixed positions in parent classes.
> Given that you have to "detect" this, i.e., dispatch on the class to find the
> true loc of the slot anyway, I seem to recall there's an implementation
> technique whereby at no cost you can detect old instances and know to update
> them on any use... Maybe I'm misremembering some of the details, but that's
> all that's left in my brain on this. Someone else can probably elaborate.
> In any case, it's possible that some particular implementation worked them
> into a performance corner, but it's unlikely that speed and correctness are
> really in conflict here.
Since CLISP also doesn't support change-class, I assume that their
implementation of CLOS lacks the decoupling of an instance from
its unadjustable slot-storage that is needed in order to support
changing the storage without changing instance-identity...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre R. Mai wrote:
> Since CLISP also doesn't support change-class, I assume that their
> implementation of CLOS lacks the decoupling of an instance from
> its unadjustable slot-storage that is needed in order to support
> changing the storage without changing instance-identity...
Yes. See section the implementation notes (see section 4.3 in
clisp.sourceforge.net/impnotes.html) where it states
4.3.6 Redefining Classes
Redefining classes is not supported. The function
update-instance-for-redefined-class is not implemented.
However, there is a download of PCL for clisp
(clisp.cons.org/pub/lisp/clisp/packages/pcl.sept92f.clisp.tar.gz) that
that can be installed.
I *think* that using this will implement change-class -- I tried and
AFAIK it works but I have been wrong before.
:) will
In article <··············@ID-22205.news.dfncis.de>,
Jochen Schmidt <···@dataheaven.de> wrote:
> Rainer Joswig wrote:
>
> > In article <·················@eurocom.od.ua>, "Vladimir V. Zolotych"
> > <······@eurocom.od.ua> wrote:
> >
> >> Hello,
> >>
> >> Suppose I defined a class with DEFCLASS.
> >> Then I created some instances of this class with
> >> MAKE-INSTANCE. Some time later I decide to remove
> >> a slot from created class.
> >>
> >> Would you mind tell me the sequence of actions in such
> >> situation or where I can read about that.
> >
> >
>
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/stagenfun_u
pd_efined-class.html
>
> Yes thats nice and useful - but another critical part that I miss in CLISP.
> I think it would be interesting why they have chosen to not implement
> things like "update-instance-for-redefined-class" or
> "update-instance-for-different-class". I think they want to gain speed and
> free-memory by not maintaining instance-tables.
Updating usually is "lazy", done when you try to access an instance.
You don't need tables of instances.
Sent via Deja.com
http://www.deja.com/
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> [1 <text/plain; us-ascii (7bit)>]
> Hello,
>
> Suppose I defined a class with DEFCLASS.
> Then I created some instances of this class with
> MAKE-INSTANCE. Some time later I decide to remove
> a slot from created class.
>
> Would you mind tell me the sequence of actions in such
> situation or where I can read about that.
If you really just want to remove a slot, and nothing needs to be done
in addition to e.g. move over some of the information of that slot into
other slots, then the normal sequence of events will just
automagically work, e.g.:
* (defclass demo ()
((slot-a :initarg :slot-a :accessor demo-slot-a)
(slot-b :initarg :slot-b :accessor demo-slot-b)))
#<STANDARD-CLASS DEMO {481670FD}>
* (defvar *instance1* (make-instance 'demo :slot-a 42 :slot-b 43))
*INSTANCE1*
* (defvar *instance2* (make-instance 'demo :slot-a 142 :slot-b 143))
*INSTANCE2*
* (describe *instance1*)
#<DEMO {48172995}> is an instance of class #<Standard-Class DEMO {4815DAAD}>:
The following slots have :INSTANCE allocation:
SLOT-B 43
SLOT-A 42
* (defclass demo ()
((slot-b :initarg :slot-b :accessor demo-slot-b)))
#<STANDARD-CLASS DEMO {481670FD}>
* (describe *instance1*)
#<DEMO {48172995}> is an instance of class #<Standard-Class DEMO {4815DAAD}>:
The following slots have :INSTANCE allocation:
SLOT-B 43
If further actions are needed to update instances, defining a method
on update-instance-for-redefined-class would be the right course of
action to take.
Note that the implementation is free to lazily update instances after
the redefinition in certain circumstances. To force the process of
updating, you can call make-instances-obsolete.
See Section 4.3.6 Redefining Classes in the HyperSpec for the details
of the whole class redefinition process, and possibilities of
influencing that process.
> Probably all instances should be recreated. Is this true ?
> After that I should perform all additional modifications
> which were made after when I've created instances the first time.
>
> Such situation seems to be common. So I supposed that
> specific technique is exists.
It is indeed common, and for the simple scenario you present, no
action is needed on your part. Welcome to the wonderful world of
Common Lisp, where hard problems have been solved for you, and the
impossible becomes tractable ;).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
This is a multi-part message in MIME format.
--------------4F95532C36BA5752E227F6EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Pierre R. Mai" wrote:
> ... Welcome to the wonderful world of
> Common Lisp,
You're right, wonderful, undoubtedly.
--
Vladimir Zolotych ······@eurocom.od.ua
--------------4F95532C36BA5752E227F6EA
Content-Type: text/x-vcard; charset=us-ascii;
name="gsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vladimir V. Zolotych
Content-Disposition: attachment;
filename="gsmith.vcf"
begin:vcard
n:Zolotych;Valdimir V.
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
·····················@eurocom.od.ua
x-mozilla-cpt:;0
fn:Valdimir V. Zolotych
end:vcard
--------------4F95532C36BA5752E227F6EA--