Re: Entity and Identity

On Jul 21, 8:09 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message

> > In OO, object identity is usually regarded as determined by object
> > location and is independent of object state. That of course is very
> > different to your first sentence above where you say you prefer to use
> > the object's state as the basis for identification.
>
> Thanks for clearing that up. I should clear up that I'm thinking about
> storing information about "entities" in an SQL database, and not about
> storing that information inside objects in an object world. Some database
> designers attempt to copy the OO paradigm and try to assign each object
> (what I refer to as an "entity") an OID. The OID is usually the first
> column in its table, and is generally the primary key. Foreign key
> references to an OID are generally used just as if they were pointers in a
> world that's based on pointers.

In OO, objects are state machines, not "entities" about which we may want to record information.

I have no idea why an OO programmer would want to pretend that employees, companies, departments, teachers or courses are state machines running on their computer! It's a ridiculous suggestion.

It's also silly for an OO programmer to think that an element of a set of tuples recorded in a relvar represents a state machine.

> I had understood that an object's identity was independent of its state, but
> had failed to appreciate that an object's identity was determined by its
> location and nothing else. Your response helps in that regard.
>
> That could make defragmenting an object space into a royal pain. You have
> to locate and update all the pointers, or else you invalidate the pointers
> you don't update. You can build a garbage collector that doesn't
> defragment, but I don't like where that road leads very much.

One can for example distinguish between physical memory address and virtual memory addresses. Also many OO systems allow for objects to be physically moved by the garbage collector and indeed end up with different virtual addresses. This is achieved by defining yet another layer of "virtual" addresses for object references in order to establish identity. A common approach is for object references to involve an indirection which could be achieved using a pointer to a pointer or an index in an array of pointers etc. One could regard the object reference as a logical identifier for a physical location. Distinguishing logical addresses from physical addresses is all relative.

This distinction also exists for OIDs for persistent object stores. In the literature OIDs are called "logical" if there is an indirection to the physical location on disk.

> > However in the context of composing complex state machines out of
> > simpler ones it is entirely appropriate to identify state machines
> > independently of their current state. More to the point it wouldn't
> > make sense to do otherwise. For example two stack objects (i.e.
> > simple state machines that support push and pop operations) used for
> > entirely different purposes within a containing state machine may
> > occasionally have the same state. It wouldn't make sense to say there
> > is only one stack object whenever that happens. In fact the
> > containing state machine will normally specify exactly which stack
> > object a given operation is to be performed on. That wouldn't be
> > feasible if object identity was determined by state not location.
>
> > I find it hard to see how one could define "object" such that object
> > identity is determined by state not location. You appear to be
> > thinking about eternal, abstract mathematical values, but it doesn't
> > make much sense to say that values have state (because that suggests a
> > value can change) or location (as though a value exists in time and
> > space).
>
> Other people in other discussions have elaborated at great length about the
> distinction between a value and a variable.
>
> A location, in the sense that you and I are using that word, is a location
> in memory.

Not really. I'm using "location" in a very abstract sense. I allow any mechanism that allows one to "access" a state machine given some "address".

> The contents of memory are variable. At the moment of
> retrieval, the contents provide a value.

No! All state machines have state, but not all state machines are variables that hold an abstract value.

> I don';t think it matters whether
> the memory space is in RAM or on disk. And the address provided by apointer
> can go through one or more mapping operations before finally resolving down
> to a physical address.

Well said. Received on Wed Jul 22 2009 - 04:37:49 CEST