Peter Ludemann wrote:
> If two things LOOK the same, then they ARE the same. It's called
> "referential transparency" and it's a Good Thing, as opposed to
> "pointers" which are a Bad Thing. Why confuse your life with "object
Even if two things LOOK the same then they are not the same. If they
were the same you could never make a copy from anything. If this is
true in reality then there is no reason to be untrue in programming
> And why do you want to use the memory address for object identity to
> identify it --- an address can change during garbage collection. Why
> not use a time stamp of object creation? Oh, it's for efficiency
> reasons, you say ... ah-ha!
You always have a memory address even you don't want to have one.
This address will identify your object even if you don't want it.
> But let's suppose that you really really really do need to identify a
> particular subtree. In other words, you want to NAME it. No problem:
> just create a dictionary (hash table) that maps names to subtrees.
> That'll let you have two differently named entries which might happen
> to have the same values. And it won't expose pointers. And it'll be
You are able to give the same name to different objects but you cannot
place two objects on the same place.
> Repeat after me: "if two things look the same and act the same, then
> they are the same". Don't depend on some hidden property (pointer) to
> differentiate them. If there are important differences, then don't be
> shy: bring them out in the open and NAME them.
I prefer not to repeat :-)
> [I once took an object-oriented database that used object-IDs and
> translated it to a relational form which just used names for things;
> performace improved by about about an order of magnitude. But that's
> another rant for another day ...]
What was the OODB based on? Perhaphs on a relational db?
-- MfG/Bye/Udv - Simon Istvan - mailto:email@example.com -