Re: Entity and Identity

David BL wrote:

[...]
>> >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".

Immutable. No variables. Constructed and yielded, but never changed. I believe this is becoming more and more popular.

>Also can't they be regarded as trivial state machines?

Single-state machines, perhaps.

A less extreme alternative is to use classes to define traditional data types, atomic or structured. *Only* variables. Trivial state machines, with the states being the values of the variables. This programming style is called 'procedural' or 'imperative', it predates OO and relational databases and it's not going to go away.

Finally, ADTs can be used to express nontrivial state machines, i.e. in which dynamic constraints (formal or informal) are considered part of the specification.

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

No. And I agree with Nilone that polymorphism on state machines is pretty hairy.

>Also what exactly do you mean by an abstract data type? For example,
>is an abstract interface for an output stream an ADT?

I believe most people would call it that, including the intended behavior. In an OO programming language, you don't typically specify behavior within the language. E.g. an interface IStack with methods push, pop and isempty doesn't usually specify within the language that an implementation is supposed to behave like a FIFO rather than a LIFO, yet this is probably the intent of whoever wrote that interface.

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

For me it's the reverse: all classes implement ADTs, whereas only some define data types.

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

Looks like a good illustration of the mechanism to me.

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

I don't follow. What does it mean for an object to have identity as a state machine? What kind of mapping do you have in mind between objects in object models in computer memory and humans?

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

But object models don't necessarily come with such pretenses. We don't need to map objects to you or me, we can map them to GUI objects on the computer screen, or printers attached via the network, or persons walking around in SimWhatever, etcetera.

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

The only reason it's laughable is the normal direction of control: we can't usually *control* opr *observe* an employee through an Employee object in an object model. As soon as we all have our electrodes installed, it will not be laughable at all.

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

I'm saying that processing, behavior, business logic, also needs to go somewhere, in an organized, maintainable way; database models can't express it, and OO models typically provide space for it. Unless you don't use that space in your design, of course, and treat objects as structured variables, defeating their purpose.

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

Now you're reversing problem and solution - variables are the problem!

>For example, how would a set<int> be mapped to a set
>of variables (by analogy to an O/R mapping)?

Why would you want to do that? The fewer variables, the better!

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

Yes, aliasing is a problem. The solution is to use as few references as possible. That's what the ADTs are for.

-- 
Reinier