Re: Entity and Identity

"David BL" <davidbl_at_iinet.net.au> wrote in message news:f806f72e-b25c-474d-b403-3cda6fb09304_at_v23g2000pro.googlegroups.com...
> On Jul 20, 11:51 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
>
>> Anyway, my view of identity (or of identification, if you prefer) is that
>> an
>> object's state is all we have to go on as the basis for identification.
>> In
>> particular, an object's location (as specified by a pointer) or its
>> trajectory (a history of pointers over time) are unavailable for purposes
>> of
>> identification. This view of identity fits pretty comfortably into the
>> relional model, but it runs afoul of object oriented thinking at least
>> two
>> important ways. Frst, if an object can conceal part of its state
>> (encapsulation), then it necessarily can conceal some of what needs to
>> be
>> known to identify it. Second, if two objects are identical in state,
>> then
>> they are the same object, even if they differ in location (at the same
>> point
>> in time). I'll call this the "Doppelganger effect".
>
> I find that confusing because it's not clear when you're talking about
> your view of identity versus the OO one.
>

I was talking about my view of identity, and why it doesn't fit well with the OO view of identity. My understanding of OO is a little hazy.

> 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.

What I really liked about the article I cited in my OP is that the author doesn't dismiss either OO thinking or relational thinking as nonsense perpetrated by inderior minds. The article's understanding of how OO works is better than mine.

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.

> 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. The contents of memory are variable. At the moment of retrieval, the contents provide a 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. Received on Tue Jul 21 2009 - 14:09:37 CEST