Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

A long time ago, in a galaxy far, far away, "Marshall Spight" <mspight_at_dnai.com> wrote:
> "Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0406071913.48e8fc07_at_posting.google.com...
>>
>> Although brown appears three times in the script, XDb1 normalizes the
>> second two by making them references to the first one. There is only
>> one brown in XDb1's db. Using RM#1 or #2, brown is stored three
>> separate times.
>
> Would that mean that if John's name is brown, it would be stored in
> the same place as the color brown? And would that mean that if
> the UI designer wanted to change all browns to umber as part of
> a UI redesign, that it would change John's name?

.. And this is the very same dilemma that comes about in various object-oriented languages when you ask for a "copy" of an object.

A "copy" and a "reference" are NOT the same thing, and if you have a tree of references, it is anything but obvious what is desired, whether:

1. A reference to the subtree, or
2. A newly formed tree that consists of copies of all of the items in the subtree.

If you use a), then modifying objects will modify all references, which means that if "Brown" was pointed to five times, ALL five instances will get changed. That's bad if all that was supposed to happen was that ONE of the people named "Brown" turned out to instead have the surname "Browne." You modify "Brown" ==> "Browne", and a bunch of people turn out misnamed.

If you use b), it is troublesome to determine just where the copying stops...

-- 
output = ("cbbrowne" "_at_" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/lisp.html
"Note that if I can get you  to `su and say' something just by asking,
you have a very serious security problem on your system and you should
look into it."  -- Paul Vixie, vixie-cron 3.0.1 installation notes