Re: Object identity


David Barrett-Lennard wrote:
Mark Nicholls wrote:
I followed your thread on and off...and don't really see what the big
problem is

Lahman and I disagree and we're both rather stubborn :)

your view of 'interpretation' is text book....the
application to identity I would have thought is quite sensible

Its application to object identity is what I regard as the
misconception.

hmmm


I propose that interpretations have *nothing* to do with the identity
of object-types. Instead object-identity is merely associated with the
instance in memory.

yes I agree....but you don't reject the interpretation that maps
(object) instance to (problem domain) entity?.......

identity is synonymous (to me) with instance.....so that is
inconsistent to me.


Furthermore I see know reason to distinguish
instance and object.

neither do I.....and I believe neither does probably 99% of main stream
OO texts.

In other words, by definition an object is an
instance in memory.

yes....and to me identity is synonymous with it.


By contrast, a value-type semantically represents a particular entity
(eg number) under an interpretation. Many instances in memory of a
value-type are allowed to represent the same entity. For example there
can be many ints in memory that simultaneously represent the number
123. In other words it is permissible for the interpretation mapping
to not be 1-1. That is precisely why you can't assume that two
different instances in memory represent different entities. You always
have to compare the state.

OK, ...the thing about the 'number 123' is that it is never anything
else....it's state is fixed (I've recently talked to Mr Kazakov about
exactly this point).......so 'representing' multiple times is fine.

BankAccount.Balance = 123....is different....if I represent that
multiple times then I'm in trouble.

The point is about it's volatility of state.

you can have as many non volatile objects in the domain of your
interpretation as you like.

volitile ones must map 1:1.....(or you model must map to a model that
maps 1:1....it's easier just to say 1:1)


....the
problem seems to exist around how to define identity.

<snip>

What you seem to be describing here are attribute ADTs, which are fully
supported in OOA/D and partially in most OOPLs. But attribute ADTs
aren't first class objects (though a particular language compiler may
implement them that way) -- they describe specialized data structures.

Your definition of "object" has nothing to do with (pure) OO.

You can keep saying this, but it doesn't make it true. Challenge: Cite
an established OOA/D author who defines an object as anything other than
an abstraction of an identifiable problem space entity and who does not
make a distinction between that abstraction and its instantiation at run
time as a memory image.

I've already said that OO texts are too informal.

I completely agree....though DbC offers a way forward.


For starters, from the Dictionary of Object Technology...

Instance n. 1 (a) Any object instantiated according to the definition
provided by the given class.

Object n. 1 (a) Any abstraction that models a single thing.

Yes, I think that's silly.

Remember that I claim that the confusion about the semantics of object
identity is rather wide spread. People who use OO to model entities
come out with quite different views than people who use OO to develop
complex state machines.

it doesn't matter that the models are different only that they are
correct...i.e. isomorphic (at the specification level) to the problem
domain....all else is effectively just labelling.

In practical terms I draw a distinction between modelling entities
outside the computing space, versus developing a state machine.

this doesn't make sense to me....I see no difference.

I see a difference between the model of a theory called 'reality' and
the model of the same theory in the computer space....but only in
practical terms.

A proposition derived from the theory must be true of both, in
practical terms we use computers to emulate/predict 'reality', but we
could just as easily do it the other way around....e.g. using pen and
paper to predict the addition of two numbers before we press the '='
button on the calculator.

In the
latter case, an isomorphism of the computational machine, is just
another computational machine (albeit abstracted away from the
hardware), but in the end doesn't seem to serve any great purpose,
unless it has simplified the state machine down to something much
easier to reason about.

not really big on state machines myself....so I can't comment.

We generally cannot make it simplified (less complex), we can only
metamorphosize it's representation into something more easy to reason
with......e.g. like doing complex arithematic in polar coordinates,
rather than cartesian.




Let's use some consistent terminology and *always* use the word entity
for particular things that exist independently of the computer. Or do
you somehow distinguish between entity and object, even before you
compile and execute the code? If you do please provide a sufficiently
formal definition so I can understand what you mean.

When have I used 'entity' to mean anything except things that exist
independently of the computer? When have I not fully qualified them as
'problem space entity'? In the quoted text I am specifically talking
about /objects/, which are design abstractions that /represent/ problem
space entities. The terminology I am using is standard OO terminology.


You use the standard words but not the standard meaning.

See above.

Objects obviously exist outside the execution context because they are
models that the developer provides during design. (In a model-driven
development that will be long before the 3GL code is even written, much
less executed.) That's why I pointed out a couple of messages ago that
there is a difference between 'object' and 'instance'. There are three
levels here:

entity -> object -> instance

which can be paraphrased as:

reality -> abstraction -> execution instantiation


There are only two levels for me : Entity and object. Object is a
synonym for instance.

And that view is not consistent with the OO view, as demonstrated above.

As a practical matter one needs to define instances separately simply
because computer programs take finite time to execute and the
computation model is fundamentally serial. So one must be able to
distinguish life cycles of instantiation (i.e., times when the object is
available and times when it is not). That is important to things like
heap reuse. It can also affect relationships (e.g., dangling pointers
when the instance is deleted). IOW, one can't have a rigorous execution
model unless one can characterize when objects are instantiated and when
they are not.

I prove an implementation correct by showing that the run time system
is isomorphic to a hypothetical system that is simpler and easier to
reason about. That is far more rigorous than the above.

i.e. the specifacation that it models....if it does model the
specification then all propositions derived from the specification must
be true of the model.

It is the basis of scientific thought....all else is theology (which is
valid where scientific thought fails).

Yes. It relates to axioms and theorems - the basis of mathematics.


I have no problem with an object (ie an instance of a class in memory)
that can have fields changed, making it suddenly represent a different
entity under some interpretation. This is allowed because unlike RM,
OO doesn't itself come ready made with semantics that relates back to
an interpretation. I'm somewhat with Bob Badour when he likens OO to a
methodology for "constructing large unpredictable state machines out of
small predictable state machines". Now I wouldn't go quite that far,
but it does seem clear that the onus is on the programmer to formally
prove that an OO program will solve the problem at hand. Using OO can
be as dangerous as assembly. You have complete, unrestricted access to
a Turing machine. You can express logical, correct solutions as well
as incorrect ones that sound right but require careful analysis to
reveal subtle errors. This promiscuity allows the OO developer to
create wholly new algorithms and techniques. But that power and
generality comes at the price of only low level implicit semantics.

The onus is on someone to prove that /any/ software works correctly. As
it happens, OO software is unique because one can demonstrate
correctness at the design level since well-formed OOA models are
executable in themselves.


You're just talking about design by contract, which is always needed
for imperative programs. Any (well written) C program can also be
proven true at the design level.

No, I am talking about the OOA model being executable and, therefore,
testable.


I imagine you think that a class diagram always captures most of the
design. I use OO for systems programming, and in that domain a class
diagram is not so useful. The problems I solve are mostly algorithmic
in nature. For example, I'm currently working on a sub-system to
partition objects into spaces that are independently garbage collected,
and support shared read and exclusive lock modes. I'm definitely using
OO, but the class diagram is simple and not very interesting. Most of
the detail is in the locking and garbage collection algorithms. I find
C++ to be a reasonable (but far from ideal) way to directly express the
algorithms. Separate documentation is required to formally prove
correctness of the algorithms.

I'm afraid your assumption is incorrect (first sentence). A Class Model
only defines static structure. Problems cannot be solved and models
cannot be executable without a dynamic description.

Good, we agree.


hmmmm....I don't..it depends on the nature of the class model...but
this is a side issue.
<snip>

Seems a little off-topic :)

yes

<even bigger snip about the distinction between object and instance>


The definitions I have provided are not "alternative definitions"; they
are the standard OO definitions that can be found in any popular book on
OOA/D. The point being that there is no "misconception" about the OO
paradigm.

I disagree.

so do I.....give up...many have had the dreaded 'DOT' argument, Lehman
has aided my thinking considerably (genuinely) by forcing me into
positions where I know what I think, and know what I don't think.



Finally, with the exception of getting into the muck of 3GL type system
definitions, I believe I have responded to all the points you have made.

I think we have reached an impasse. Let's agree to disagree.


oh you have.

my point is....

how do you define identity?....formally....well.....approaching
formally....for me object and identity and instance are synonymous.



You've ducked the question.

or was the answer; 'object', 'idenity' and 'instance' are sysnonymous?

.

Quantcast