Re: Object identity


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? 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?

The discussions on comp.object reveal disagreement
over the fundamentals. I haven't seen a book on OO that is anywhere
near sufficiently formal.

Given the very numerous and different existing object models and
approaches to OO, no usable definition could be made IMHO that would
take each and every particularity into account - either the definition
would rule out large parts of the OO world, or it would be more of a
list of exceptions and arbitrary stuff than a usable, formal,
theoretical definition.

<troll>
Even the RDBMS world (I mean existing SQL systems) manage to be somewhat
standardized and consistent in contrast !-)
</troll>

Some proper science should stop all that silly rabbiting on.

And spoil much of the fun too !-)

The fun part for me is reading Bob Badour let loose. Though I haven't
been on the receiving end yet!

Cheers,
David Barrett-Lennard

.

Quantcast