Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!mips!pacbell.com!decwrl!argosy!kentb
From: kentb@argosy.UUCP (Kent Beck)
Newsgroups: comp.object
Subject: Re: Reference Semantics (sic!)
Message-ID: <1380@argosy.UUCP>
Date: 19 Jun 91 22:55:40 GMT
References: <850@tech.abccam.abcl.co.uk>
Sender: news@argosy.UUCP
Reply-To: kentb@maspar.com (Kent Beck)
Organization: MasPar Computer Corp, Sunnyvale CA
Lines: 22

While not claiming that my Smalltalk skills are up to Phillip Yelland's
stature (:^) there are some aspects of my style which minimize aliasing
errors.  First I strictly partition my objects into real objects and
values (objects whose state is set at instance creation time and never
changed).  I always use Rectangles and Points as values- if I ever
have to modify one in place because I can't add a lower level protocol
I use a strict copy in/copy out protocol.  Similarly with real objects-
if I give one visibility I make a copy, and copy it when I get it back
(the practice of safe objects).  If I am ever tempted to share objects
in contradiction to these rules for performance sake during early
development I smack myself.

"Ah, but don't you do lots of object allocation and isn't it a performance
problem?" the straw man says.  Yes and no, respectively.  The style I have
described above deliberately spends time in the garbage collector so that
the resulting program is simpler and more robust.  In my experience,
however, when a well factored program needs performance and object allocation
is a problem it is always possible to recast it so that the performance
critical portion is in one object.  I can't prove that this will always be
the case, but I do bet my livelihood on it daily, so I'm pretty sure of it.

Kent Beck