Re: Entity and Identity

On Jul 23, 6:50 pm, Brian <br..._at_selzer-software.com> wrote:
> On Jul 22, 3:21 am, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Jul 22, 12:57 pm, Brian <br..._at_selzer-software.com> wrote:
>
> > > On Jul 21, 11:15 pm, David BL <davi..._at_iinet.net.au> wrote:
> > > > In your original statement you implied that location was part of an
> > > > object's state. That was the part I disagreed with.- Hide quoted text -
>
> > > I stated that a difference in location constitutes a difference in
> > > state.
>
> > I don't like that point of view. Typically the possible states of a
> > state machine can be identified independently of the identity of the
> > state machine. It then follows that it can be possible to say that
> > two distinct state machine instances (i.e. at different "locations")
> > happen to be in the same state at a given time.
>
> 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.

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

> 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 eight nodes in your cube of 1-
> > > ohm resistors are distinct even though they can only be distinguished
> > > relative to one another, and in the same way states at different
> > > locations are distinct, even if all of the fields in each state
> > > contain identical values.
>
> > That discussion will probably lead us into confusion between state
> > machine and value!
>
> I don't think it will. There are state machines and there are values,
> and there are values for state machines. So you can have a state
> machine, o, and a value, v, and a value for a state machine (o,v).

In the sense that source code is data, I regard a state machine class as an abstract value whereas a state machine instance running on a physical computer exists in time and space. The former is a pure mathematical abstraction divorced from the physical. The latter is an abstraction over the physical. This is commonly called the compile time versus run time distinction.

It potentially gets confusing given the idea of composing state machines, which can be described at compile time and also somewhat independently at run time. For example, one can instantiate a state machine class multiple times within a containing state machine class. However, in that case the instantiations are part of a containing abstract value. This is similar to instantiating an abstract subcircuit  value within a containing abstract circuit value, and not to be confused with a physical instantiation (or "appearance") of a circuit in time and space. Received on Fri Jul 24 2009 - 02:09:24 CEST