Re: Object identity

Responding to Bouma...

This is a different problem. A true clone function creates different
instances with unique identity (address) but the instances all map to
the same object abstraction Employee{name,...}. This creates an even
nastier set of problems for referential integrity for relationships
when one changes the salary. The solution here is to break the
thumbs of any developer who does something like this.


Not necessarily. The thing is that what's in memory is stale by
default as the real data is actually in a central persistent storage.
Classic example is an application where two people individually
purchase an item using the application, while there's just 1 left.
Unless your purchase state machine is just 1 state, you'll run the risk
of selling an item which isn't there. You could of course use things
like reservation during the process, transactional memory etc. but the
root cause is that two processes perform actions on copies of the same
entity in the db, which is the true application state, not the state
in-memory.

I think we are talking about two different things. Persistence is external to the problem solution where the objects and instances live (i.e., it is out of their scope). If one has a problem with synchronization, one manages that through some form of handshaking in the interface.

I assumed the cloning issue was within the scope of object instances. Within the scope of the problem solution one has referential integrity chaos if there are multiple instances of the same object.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.