Re: Object identity

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


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). It can be handy for
low-level, critical parts, but OTOH breaks the consistency of the model.
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.


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xxxxxxxxxxx'.split('@')])"
.

Quantcast