"Pattern Hatching"

Daniel Vainsencher danielv at netvision.net.il
Tue Dec 3 19:21:07 UTC 2002


"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> A variable is not a collaborator
> any more than an address is a house.

An abstraction doesn't cease to be one just because it is leaky. In my
experience helping people to grasp coding and design I've often found
that using mechanistic, precise terms and using impressionistic,
imprecise terms and metaphors are both useful, for different purposes. 

And let's get this out of the way - in my experience they are both
useful, and I don't really care if you consider one of them Wrong. I
would be glad to hear about superior alternatives, if they address my
concerns, or about novel problems with the ways of communicating I
describe.

When someone is confused about the machines reactions, explain the
machine, in all the required precision. When someone has no clue about
how to design (or go about some other relatively new activity), use the
closest, most familiar metaphor for that person that will give him a
grasp on the topic, and that will scale and make it easy to switch to a
better explanation when the metaphor runs out of steam. Responsibilities
and collaborators can sometimes be good metaphors for design - most
students are very used to thinking about systems of people
communicating, so get them started thinking about that as a guide to
design, and explain the differences later. 

And in such cases, I think it's completely appropriate to label the
instance variables "collaborators", even if they are really only
class-local names for instance specific storage of references to objects
that are sent messsages. As far as the code is concerned, there is no
object, and the reference that turns the variable into the referenced
object transparent. So in the code, the x and the y are the
collaborators. This is not a precise way of describing things, but it's
concise, and as far as some aspects of design are concerned, it contains
all the important information.

In some contexts one doesn't want to get people too worked up about
their syntax or even semantic errors - it would just be a diversion from
what you really want to talk about.

Daniel Vainsencher



More information about the Squeak-dev mailing list