[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 

-- Jecel

More information about the Self-interest mailing list