Re: Object identity


Dmitry A. Kazakov wrote:
On 29 Jun 2006 10:04:54 -0700, David Barrett-Lennard wrote:

Bruno Desthuilliers wrote:

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.

To me identity is a value of some possibly different type, of which it is
known that these values are comparable (exists =, transitive, reflexive,
commutative). Quite simple, IMO.

It is necessary for object identity to have those features, but not
sufficient. You have to tie down the semantics to the point where you
can predict how source code will behave. Eg

Employee* e1 = new Employee;
Employee* e2 = new Employee;
e1->SetName("Einstein");
e2->SetName("Godel");
assert(e1->GetName() == "Einstein");
assert(e2->GetName() == "Godel");

We know those assertions won't fail because there is a binding of
identity to the instance. That's part of the formalism of OO.


For
example, Semaphore, Thread, Window, PrinterProxy. Eg what does it
mean for two different thread instances to have the same value?

It means that they have it same. Consider a redundant system. In such a
system several redundant threads would traverse same states and could be
considered same as long as states don't differ.

Same semaphores: consider two redundant partitions of a distributed system.
In each partition there exists a semaphore used for local interlocking.
These are logically same. One can imagine some global deadlock monitoring
program which would enumerate all semaphores in all partitions and check
their states [=values]

Yes, but not commonly done.

In C++, operator==() is optional. That makes good sense to me.

Right. It is the domain to decide if == has to be defined. It makes a lot
sense to have no == defined, because == or its absence is a part of
behavior.

Agreed. That was really my point.

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

I think it would be wrong to mix semantics [the value of an object] with an
ability to check it. Comparing values might be incomputable, in strict
sense. Because values are outside the language.

Yes.

I doubt whether it's always reasonable to characterise an object by its
"value", as if that can exist and be interpreted independently of the
object. What is the "value" of a critical section? Is it meaningful
to talk about its state (ie which identifies whether it is currently
locked, by what thread and how many times by that thread) outside the
context of the executing process? Clearly not. When I think of
values, in my mind I think of an interpretation map to some entity
outside the computer space, such as when a 32 bit int represents a
number. I have trouble thinking of a critical section this way.
What's the entity that it represents? It seems easier to just say
that it is what it is - an instance in memory that has identity, state
and behaviour.

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: Semantics and STL/DTL
    ... I think the reason is the semantics described sound familiar, ... "Coupling: qualitative measure of module interdependence/communication (from ... languages because the programmer can't infer any meaning from it. ...
    (comp.object)
  • Re: Semantics and STL/DTL
    ... I think the reason is the semantics described sound familiar, ... "Coupling: qualitative measure of module interdependence/communication (from ... languages because the programmer can't infer any meaning from it. ...
    (comp.programming)
  • Re: Translator design decisions
    ... languages, and a couple of semantially similar targets, it seems to ... There is a lot of compiler infrastructure to leverage, ... present in any given language that pervades the semantics and that is ... special hooks FORTRAN needed for that suite. ...
    (comp.compilers)
  • Re: proof that most etymologies are only fairy-tales
    ... bear and bear (omnivorous ... I am sure there are no homonyms in any PIE reconstruction - since ... it's just about plausible from the semantics that they're the same ... which is phonetically pretty complex as languages ...
    (sci.lang)
  • Re: Object identity
    ... programming languages. ... consider two redundant partitions of a distributed system. ... In each partition there exists a semaphore used for local interlocking. ... multiple candidates for value semantics. ...
    (comp.object)