Object Ownership

In C++ and other object-oriented languages, owership is a very important concept. Thus, if you have created an object (e.g. a DMPoint3) and added it to a DMPoint3Vector, does it still exist except in the context of the Vector? Could altering the value of the DMPoint3 outside its environment in the vector affect the Vector? The answers to these depend on how you create the tools and use them.

One philosophy - the default in C++ - is that objects are COPIED into other environments (an argument in a subroutine call copies the object). HOW it copies it is also something you have to think about - it might make copies of all the contained objects (recursively - sometimes called deepCopy) or it might just copy the member data - which if they were pointers would still point to a single object after being copied. C++ often required a 'copy constructor' of the form:
public FOO(FOO f) {...} which was called as:
FOO f(g); which would make a copy of g. (Incidentally, manually converting CBMT copyConstructors to Euclid may have given rise to a few errors.)

In java the default is that copies are simply additional refernces to the same object. Thus:
FOO g = someFunction();
FOO f = g;
simply leaves f and g pointing at the same object. If either f or g are reassigned (or go out of scope), the object still exists, but if both are reassigned, the object gets collected by the garbage collector at some stage.

Therefore, particularly if you come from C++, you may not realise you have many references to the same object. If this allows you to modify the object it could have unexpected side-effects. Example:
DMPoint3 p = moleculeA.getPoint(27);
DMPoint3Vector moleculeB = new DMPoint3Vector();
Would you expect the last operation to affect moleculeB? Would you want it to? There is no clear answer to this - it depends on what you want to do - for example if B was a subset of A and used to view part of A as A was varying, the code above would do just that. If, however, you had forgotten all about A it could be a disaster!

For this reason I have provided some routine which simple transfer references and some which make copies - sometimes shallowCopy and sometimes deepCopy. For example, most classes have a recursive copyConstructor (and I'll add those which don't). However, it is often valuable to assign a superclass to a class and so many classes have a constructor from their superclass which is a simple transfer of refereb]nces. (In C++ you could do this with an LHS cast).

I have just started to add COPY/REFERENCES to the documentation, so absence of this tells you nothing - sorry!

Good luck!

PeterMR, July 1996.