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
> identity"?
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
languages.
> 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
> efficient.
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:istvan.simon@usa.net -
|