Re: Entity and Identity

On Jul 28, 7:08 am, rp_at_raampje.(none) (Reinier Post) wrote:
> 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 want to clarify what you mean by stateless objects. Note firstly that objects with no members or only immutable members can be deemed to have a single state. It's not clear to me whether that means they are "stateless". Also can't they be regarded as trivial state machines? Note furthermore that objects of classes with no member variables that implement abstract interfaces normally have type information in order to support dynamic polymorphism. Do you regard such objects as stateless?

Also what exactly do you mean by an abstract data type? For example, is an abstract interface for an output stream an ADT? I would expect an ADT to be limited to types where it can be assumed that objects of that type are deemed to be variables that hold an abstract value (that's what a *data* type is). That makes me think that all classes define types and/or implementations of abstract state machines but only some do so for ADTs.

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

The first book I ever read on OO (back in the early 90's) introduced the subject using a hierarchy of employee classes - and it talked about how it's useful to have a polymorphic GetPay() method, e.g. so a sales employee can override to add a commission on top of the inherited base salary.

I now consider such books to be ridiculous because they are founded on an approach which lacks conceptual integrity. For example, objects have identity as state machines but not as humans, so logically one should be willing to create any number of objects that model the *same* employee (perhaps in different ways). This idea of 1:1 mapping informal entities in the real world to objects within an abstract machine seems completely arbitrary to me because it is founded on a pretence (that an object actually *is* the external entity that it models).

When I use OO, I think of an object has having a well defined identity and role within the abstract machine. I try to use class names that reflect that role. In that sense a class called "Employee" is laughable.

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

Are you saying that OO is used to process the information, but not to record the information?

> >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 see that as the issue. I have no problem calling a variable that supports arbitrary assignment a simple (but rather uninteresting) kind of state machine.

The problem I see is that most generally tuples in a set don't have an immutable identifier allowing them to be mapped to a variable in a useful manner. For example, how would a set<int> be mapped to a set of variables (by analogy to an O/R mapping)? How do you efficiently locate a variable for a given value? It would seem necessary to record a map from int to the address of the associated variable. When a variable is updated, it is necessary to update the map. However what happens if one of the variables is changed so it holds the same value as one of the other variables? Does it suddenly disappear? How does the code avoid access violations?

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

Agreed. Received on Tue Jul 28 2009 - 09:38:29 CEST