Re: Entity and Identity

On Jul 24, 9:19 pm, Brian <br..._at_selzer-software.com> wrote:
> On Jul 23, 8:09 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Jul 23, 6:50 pm, Brian <br..._at_selzer-software.com> wrote:
>
> <snip>
>
> > > It may again be splitting hairs, but I would argue that it is the
> > > possible sets of field values rather than the possible states that can
> > > be determined independently, from the standpoint that a state is a set
> > > of field values /for/ a particular state machine and thus cannot be
> > > divorced from it.
>
> > Some definitions of an abstract state machine don't have any concept
> > of "field values". E.g. sometimes a state machine is defined by an
> > abstract set of states, a transition function etc.
>
> So? Isn't a set of values still a value?

My point is that you are complicating the discussion by introducing the term 'fields'. For example, what does that mean exactly for an object with no member variables and its state is associated with I/O to a hardware clock based on a crystal oscillator and binary counter?

> > > For there to be a state requires first that there
> > > be a state machine!
>
> > That makes it difficult to talk about a state machine 'class' (using
> > OO speak). For example I may want to use {0,1,2,3} to represent a set
> > of possible states for a class of state machine, and write proofs
> > about behaviour of all run time instances of that class (before I've
> > even run the program).
>
> I don't see how treating states as mappings between the domain of
> objects of a particular type and the domain of possible values for
> those objects would make it any more difficult to talk about a state
> machine 'class.'

An object class is not a domain of objects. You can't form sets over things that exist physically in time and space. The whole point of the axioms of ZFC is to clearly define what is and isn't a set and in its purest form the only permitted elements of sets are themselves sets. Even though that assumption can be lifted, sets (and therefore their elements) are *always* pure mathematical constructs divorced from the physical.

What exactly do you mean by possible values for an object and how do these values differ from states? You make it sound like objects are always variables that hold values. That's one of the common confusions about OO and the meaning of "encapsulation". In OO an object is an identifiable instance of a state machine that exists in time and space, that doesn't necessarily represent a variable that holds a value.

Conversely, a variable can always be regarded as a very simple kind of state machine (and in that sense is an object). In OO it is normal to assume that a variable has a type defining the set of possible values that it may hold, and all transitions between these 'states' (where each state is associated with each value of that type) are equally acceptable. That indeed is why a circle variable is not an ellipse variable. BTW it is curious that some OO proponents argue that the solution is to disallow mutative methods on the ellipse class but forget about the assignment operator.

> > > It then follows that it can be possible for two
> > > distinct state machines to have equivalent, but not identical, states
> > > at a given time.
>
> > I agree it is possible to require that every run time instance of a
> > state machine has its own "private" set of states. But what is the
> > advantage in making that restriction? I cannot see any basis for it,
> > and a lot of good reasons not to.
>
> > > > > My line of thinking is that what is referenced by each object
> > > > > identifier is a particular object's state and that each object can
> > > > > have exactly one state at a time, so when there is more than one
> > > > > location at a given time, there is more than one state and therefore
> > > > > there must be more than one object.
>
> > > > You seem to be saying that a state machine *is* its (current) state.
> > > > I would rather say that a state machine *has* a (current) state.
>
> > > How did you come to that conclusion? If you look closely, what I
> > > actually said was "each object can *have* exactly one state at a
> > > time."
>
> > You said:
>
> > "what is referenced by each object identifier is a
> > particular object's state."
>
> > I would instead say: what is referenced by each object identifier is
> > a particular object.
>
> > I reconciled the two by assuming you believed an object is nothing
> > more than its state (and I agree with you that this pov would seem to
> > imply that distinct objects necessarily have distinct sets of states).
>
> The context of the entire sentence is "at a given time," and since an
> object can only have exactly one state "at a given time," it stands to
> reason that the object identifier [indirectly] references a particular
> object's state "at a given time."

Ok. However if you want to prove that objects necessarily have distinct sets of states you need to provide precise definitions of terms like 'object' and 'state', and show how the result follows from those definitions. I think you will find that your definition begs the question.

Pure mathematical descriptions of state machines treat the possible states as a mathematical set which immediately implies that the states are divorced from space and time, and in OO speak relate to a class (i.e. mathematical) not an object (i.e. physical).

I think our difference of opinion stems from your willingness to blur the distinction between mathematical constructs and physical entities.

As I see it, an object is a uniquely identifiable physical "manifestation" or "instantiation" of a class, and a class defines an abstract state machine with abstractly defined states. It is therefore possible for distinct objects of the same class to be deemed to be in the same (abstract) state. Received on Sat Jul 25 2009 - 06:25:58 CEST