Re: Entity and Identity

From: Brian <brian_at_selzer-software.com>
Date: Sat, 25 Jul 2009 21:23:12 -0700 (PDT)
Message-ID: <3337ee7a-64be-4505-854a-abca95b103eb_at_b15g2000yqd.googlegroups.com>


On Jul 25, 12:25 am, David BL <davi..._at_iinet.net.au> wrote:
> 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.

Are you saying that the domain of discourse cannot consist of both 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.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Received on Sun Jul 26 2009 - 06:23:12 CEST

Original text of this message