Re: Entity and Identity

David BL wrote:

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

Now you're exaggerating. In (class-based) OO, classes are abstract data types, that *can* be used to model stateful objects, (e.g. state machines), but objects can be stateless just as well. This is why an OO language is general purpose in nature.

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

Then don't suggest it. An OO programmer would typically model the static aspects of employees, etc., in stateless objects, and dynamics (e.g. enrollment procedures, hiring procedures) in stateful objects.

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

Technically, it is. Every value of the tuple is a state. But the transitions are trivial (no transition constraints). Unless you do have transition constraints, of course, which is when we start to use the term 'state machine'.

[...]

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

I think this part of the discussion is a red herring. The association of identity with physical implementation is historically understandable but unnecessary. Identity of terms can be supported as a modeling language feature on any level of abstraction. I think both of you have made good arguments why it makes sense to do so. (I try to point it out when you go overboard, which seems to happen in places, but I do support the premise.)

-- 
Reinier