| Computers Forum Index » Computer Languages (Smalltalk) » using a dictionary for all instance variables... |
|
Page 1 of 1 |
|
| Author |
Message |
| Emptist... |
 Posted: Tue Sep 29, 2009 11:12 am |
|
|
|
Guest
|
Hi,
For some reason, such as easy mathematics operation on a collection of
variables, I tried to use one dictionary to hold all otherwise
instance variables. It works fine for a while until these objects have
to copy themselves. It turns out that a copy will now be a copy of the
object and its dictionary and all objects now are just the same in
both the origin and the copy. Now I have to use deep-copy instead of
copy?
So this will prove a bad practice to put all variables into one
dictionary?Thanks.
Best Regards,
empt |
|
|
| Back to top |
|
|
|
| Bill Dargel... |
| Posted: Wed Sep 30, 2009 5:17 am |
|
|
|
Guest
|
Emptist wrote:
Quote: For some reason, such as easy mathematics operation on a collection of
variables, I tried to use one dictionary to hold all otherwise
instance variables. It works fine for a while until these objects have
to copy themselves. It turns out that a copy will now be a copy of the
object and its dictionary and all objects now are just the same in
both the origin and the copy. Now I have to use deep-copy instead of
copy?
You might just want to redefine how #copy works for your class to also
copy the dictionary (deeply enough). You can do this by simply
overriding #postCopy in your class to be something like:
postCopy
super postCopy.
myLookupTable := myLookupTable copy.
^self
though if you're actually using "Dictionary" the above is still not deep
enough because it would still be sharing its internal Associations, and
thus changing values in the copy (#at:put:) would still be changing
values in the original. But if you use a "LookupTable" instead, where it
keeps the keys and values in parallel vectors, a copy of a LookupTable
does not share slots with the original. So with that, the above postCopy
on your class should do what you need.
-Bill |
|
|
| Back to top |
|
|
|
| Reinout Heeck... |
| Posted: Wed Sep 30, 2009 6:44 pm |
|
|
|
Guest
|
Bill Dargel wrote:
Quote: though if you're actually using "Dictionary" the above is still not deep
enough because it would still be sharing its internal Associations, and
thus changing values in the copy (#at:put:) would still be changing
values in the original.
In the case of VisualWorks above is not true,
Dictionary overrides #postCopy to avoid this problem.
R
- |
|
|
| Back to top |
|
|
|
| Reinout Heeck... |
| Posted: Wed Sep 30, 2009 7:10 pm |
|
|
|
Guest
|
Emptist wrote:
Quote: So this will prove a bad practice to put all variables into one
dictionary?Thanks.
It will cost a bit of extra memory per object (one header for the actual
object,one for the dictionary holding its aspects).
There will be some runtime overhead to access the ivars.
The only way to know whether that is 'bad' is to try it and judge the
results yourself ;-)
The original designers of Smalltalk envisioned Smalltalk programmers
would do a lot of this type of experiments (which it turned out we don't
do much at all). To this end the Behavior hierarchy has been designed
such that you can add your own 'kind' of classes.
R
- |
|
|
| Back to top |
|
|
|
| emptist... |
| Posted: Thu Oct 01, 2009 10:11 am |
|
|
|
Guest
|
On 9月30日, 下午11时10分, Reinout Heeck <rein... at (no spam) soops.nl> wrote:
Quote: Emptist wrote:
So this will prove a bad practice to put all variables into one
dictionary?Thanks.
It will cost a bit of extra memory per object (one header for the actual
object,one for the dictionary holding its aspects).
There will be some runtime overhead to access the ivars.
The only way to know whether that is 'bad' is to try it and judge the
results yourself ;-)
The original designers of Smalltalk envisioned Smalltalk programmers
would do a lot of this type of experiments (which it turned out we don't
do much at all). To this end the Behavior hierarchy has been designed
such that you can add your own 'kind' of classes.
R
-
Hi,
Thanks for all the replies here.
And now I'm thinking that this might be bad since it requires extra
brain work from reader (I myself or someone else) to the code and the
system tend to have more tool supports for coding in normal way.
If there were a team work on the project this kind of experiments can
be full of fun though I have to deal with everything myself so I'm
finding it costs a little more effort.
empt |
|
|
| Back to top |
|
|
|
|
