[self-interest] A copy vs. the original prototyp in global slots
Jecel Assumpcao Jr
jecel at merlintec.com
Thu May 16 23:13:36 UTC 2002
On Wednesday 15 May 2002 11:40, Thorsten Dittmar wrote:
> I have another question. When you have an object, like the dictionary
> in globals with a slot like values (a vector) in this global, then
> normally not the global vector is in this slot, it is a copy of this
> global vector. So when you make then a copy of this dictionary, a
> more or less deep copy is made (values and keys are copied too).
> In my understanding it would be much better to use the global vector
> because then all the chances that I would make for the vector (new
> data slots) were immediately available. I know normally nobody has to
> chance a system object but the problem is the same for other
> "complex" objects.
This is a case of "defensive programming". For example:
sillyMethod: n = ( | temp <- list copyRemoveAll |
temp: temp copyRemoveAll.
n timesDo: [ temp add: '*' ].
This would work just as well (and would be more readable) if the
declaration of the temp slot had been just
temp <- list
There is no reason not to use the global 'list' as the value in the
method prototype object since the first thing we are going to do anyway
is to copy it. And there is no good reason to use 'copyRemoveAll'
instead of a plain 'copy' since we know that the prototype list is
Unless, of course, there is a chance that either I or somebody else
later editing this method can make a mistake. That is what defensive
programming is all about - lots of silly tests that don't make sense if
everything was built as it should.
> So I ask me what is the reason for that:
> - it is not the excepted behaviour that changes on the global vector
> have any impact on the one that is used in the dictionary - but
> behaviour changes have still an impact because they are made in the
> parent of this vector.
Yes, such changes might break my code. This is where a viewpoint system
like in Us might be nice - we could more easily say what we need to
remain unchanged and what we would like to have the latest version of.
Right now the way to do this would be to add an empty parent object to
our cloned vector and to copy into it any slots that must remain as
they are. Then we will be protected against random changes to 'traits
vector' and yet still automatically use any bug fixes or improvement
that don't break our dictionary object.
> - when somebody is changing this vector (by inspecting and
> manipulating it) the global one would be changed. This would be a
> good reason, but it seams to me, that for this problem this is not
> the right solution. If we want to prevent this it would be much
> better to make global objects more or less "unchangeable".
In a multiuser Self we could have global objects be unchangeable except
by people with special permissions. That would avoid most accidents yet
allow needed changes to be made.
> So why don't we use for slots in prototypes the excepted prototype
> instead of a copy of them?
Just to reduce the effects of mistakes (like somebody forgetting to
override the 'copy' method to do a deep copy, as you mentioned in the
More information about the Self-interest