Re: Entity and Identity

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?

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

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

>
> > > > 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 sub-
> circuit 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.- Hide quoted text -
>
> - Show quoted text -
Received on Fri Jul 24 2009 - 15:19:06 CEST