Re: Object identity

Bruno Desthuilliers wrote:
David Barrett-Lennard wrote:
Bruno Desthuilliers wrote:

David Barrett-Lennard wrote:

Bruno Desthuilliers wrote:


David Barrett-Lennard wrote:
(snip)


I think the OO community needs to spend a lot more time properly
defining concepts like object identity,

Seems like almost everybody agree that any unique identifier will do,
and that almost if not all all programming languages uses a memory
address for this.


I tend to agree. However, IMO there is an semantic inconsistency when
I see classes that model external entities like Employee, and classes
that don't - such as a GUI Button class. I see a fundamental
difference. An object that is associated with a GUI button is the
"real deal" in the sense that it is responsible for drawing the button
and handling mouse events. I don't see any inconsistency with
associating identity with the instance in memory as well as the button
as a GUI entity.

I'm suspicious of thinking of an Employee instance as having identity
unless one is clear that this is associated with the identity of the
model and not of the human being modelled. Furthermore I see no
semantic problem in allowing multiple models of the same entity. So
why are OO designs careful to avoid that - by using inheritance,
delegation or whatever? Something suspicious is going on! I think it
relates to the closed world assumption of RM. I propose that this
demonstrates a misuse of the OO formalism.

The company I work for at the moment is involved with geological
modelling. I have noticed that the scientists are very careful to
distinguish between the model and what is modelled. In fact they have
to routinely deal with entities that have been modelled in many
different ways. Trying to merge all models into one supermodel just
seems wrong. Supermodels should be limited to the catwalk :)



value-types versus
object-types etc.

A value-type is any type that is not an object type.


Bad luck, these two examples are relatively well defined AFAIK.


Is an Image class a value type or object type? What about an Employee
class?

Given what you name 'class' correspond to the canonical use of that word
in most OOPLs, the answer is very obviously in the question.


True in Java (say). But in C++ you get the option of defining classes
that act as value types or object types.

Please define "acting as value type" and "acting as object type".

An object type is an instance characterised by having identity
associated with its location in memory. The object is only accessed
via a pointer to its memory location. Two pointers can be compared to
see if they alias the same object - ie object identity testing.
Objects only optionally support cloning.

By contrast only the content, not the memory location of a value type
instance is significant. Therefore pointers to value-type instances
are never compared. Values always support copy and assignment, and
this always makes a copy of the "content" from one memory location to
another. The copy is said to have the same value. Value types support
equality testing. This compares the content without regard for the
location in memory.

I accept that these definitions are rather vague, and I guess in C++
it is possible to have a mixture of the two in certain cases.


Can a class be both at once in some sense? What does it mean
when a C++ class implements operator==() - ie value testing, yet seems
to also act like an object-type in other ways?

It means that the designer/developper want to implement value testing
semantic for this class. The usual case is to declare two objets as
equals if they are of the same type (or compatible types) and are in the
same state - but it's really up to the designer/developper to decide
what it means for a given class.


I wonder whether object-type and value-type are always mutually
exclusive. Maybe not, even for a particular instance.

"value-types" - or at least what I understand as being "value-types" -
only exists in languages that are not 100% OO (which doesn't necessarily
make them bad languages - no judgement call here).

I think value-types are quite value-able :)

Just about all the C++ STL classes are value types. It's nice to have
such powerful, type-safe high performance primitives. Many C++
programmers use templates far more than polymorphism. I don't know
whether people still call that OO. ie where inheritance and
polymorphism are used rather sparingly.

It can be handy for
low-level, critical parts, but OTOH breaks the consistency of the model.

I used to think that once, but have now decided that value-types are
vitally important. Used properly they seem to make code easier to
understand (never mind more efficient).

Imagine if Java treated int, float etc as objects. Every int in the
program has to be explicitly allocated from the heap. That's painfull.
It also means you need two types of assignment operators : one to
assign pointers, another to assign values. Alternatively you need to
explicitly indicate pointer indirections (such as with the asterisk in
C/C++). Either way the result is syntactically very ugly.

In "pure" 00PLs, this distinction does not exist. Now you have types
with a very straightforward "value" semantic (ie integers, strings etc)
- which in some languages happens to be immutable objects - types with a
more complex "value" semantic (records-like types) but for which (total
or partial) structural equality can still make sens, and types for which
a "value" semantic would be harder to define, like ie class objects or
function objects - in this last case, "value" equality could be defined
as "given same inputs, produces same ouptputs", but this would be nearly
impossible to test in practice AFAICT, at least in most current
programming languages.

I can think of some object types where "value" equality testing (as
distinct from identity testing) doesn't seem to make sense at all. For
example, Semaphore, Thread, Window, PrinterProxy. Eg what does it
mean for two different thread instances to have the same value? In
C++, operator==() is optional. That makes good sense to me.

I wonder if there are also some object types for which there are
multiple candidates for value semantics.

Cheers,
David Barrett-Lennard

.

Quantcast