Re: Object identity

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.

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]

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.

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

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. ... You have to tie down the semantics to the point where you ... Employee* e1 = new Employee; ... In each partition there exists a semaphore used for local interlocking. ...
    (comp.object)