🚀 go-pugleaf

In article <1dbqs8INN7qo@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> [...]
|> That's a silly guideline.  The most common reason to use pointers is
|> precisely *because* you need multiple references to the same data.  In
|> object-based programming, an object may be in different relationships with
|> other objects, and relationships are usually implemented as pointers
|> between objects.  For instance, in a family tree model, a person might have
|> pointers to its parents, children, and siblings; any particular person is
|> likely to be referenced by the children array of two parents and a parent
|> pointer of some children.

I seldom use explicit pointers for this kind of structure.  It 
consists of a *set* of individuals and *sets* of directed arcs 
between these individuals.  The directed arcs are not semantically 
just pointers, they are ordered pairs whose elements are drawn from 
the set of individuals.  Each such set of arcs defines one of
the relations you mentioned above: parenthood, siblinghood, etc..
While these may be *implemented* internally using pointers, the 
finite, non-looping, non-aliased nature of these sets allows more 
efficient code development which is easier to prove correct, optimize, 
maintain, etc..  For example, suppose I wish to perform some operation 
on all individuals - I needn't even *look* at the sets of arcs if the 
order of processing the individuals is not relevant (or, if the order 
is intended to be, say, alphabetical so the sets of arcs you mention 
are all irrelevant). 

In fact, I never think in terms of multiple *pointers* to a single 
object - though I might think in terms of multiple references of 
more restricted, more easily handled, optimizable, and debuggable
kinds.

-- 
J. Giles