Talk:Identity (object-oriented programming)

often not useful?

I'm rewriting this paragraph:

Object identity is often not useful, if referential transparency is assumed, because identity is a property that an object may contain, aspects that are not visible in its interface. Thus, objects need to be identified in the interface with a mechanism that is distinct from the methods used to access the object's state in its interface. With referential transparency, the value of the state of the object would be identical or isomorphic with the values accessible from the object's interface. There would be no difference between the object's interface and its implementation, and the identity property would provide no useful additional information.

Reasons:

1. . Weasel word: often not useful. How often? To Whom?
2. . Grammar: first sentence is a run-on which makes no sense.
3. . Semantic confusion: the author of the paragraph is almost certainly misusing the term "referential transparency", which has to more to do with symbol bindings and environments in program code.

I think I know what the author is getting at and believe I can rescue the paragraph. 192.139.122.42 (talk) 00:42, 26 November 2011 (UTC)

I hope this addresses some of your concerns:

In many situations, what you really care about is values (e.g., in a game engine, vectors and matrices of floating-point numbers), not the abstract memory regions where said values are stored (e.g., contiguous arrays of 4 or 16 elements). In these cases, it's more convenient to write your program directly in terms of value transformations (functional and logic programming) than to manually keep track of which memory region contains the particular value you want (imperative programming). Another benefit of programming with values, especially in languages with abstract data types (such as Standard ML), is that the same logical value may admit more than one physical representation (e.g., the same ordered set may be represented as two different red-black trees, balanced differently), for efficiency reasons (e.g., it is too expensive to assign to each ordered set a canonical representation) or even purely for convenience. Finally, in those cases when you do want to program with mutable objects that have a physical identity, you can still do it, since identities themselves are values just like any other (e.g., you can test them for equality, just like with numbers or strings).

Eduardo León (talk) 16:15, 26 August 2016 (UTC)

Identity is a property of objects?

I find it confusing to see identity described as a property of objects. In most object-oriented languages, objects have properties, i.e. they can be specified using a language construct. Identity is not such a property. Rather, it is a fundamental characteristic of all objects in object-oriented languages in general. So I believe some rewording is in order. Rp (talk) 16:14, 23 June 2016 (UTC)

I amended the ooening sentences to make this clear. It would be better to have a reformulation supported by a reference. Rp (talk) 12:03, 14 August 2022 (UTC)

Consequences of identity

“Identity of objects allows objects to be treated as black boxes.”

In many dynamic object-oriented languages (Common Lisp, Python, Ruby, JavaScript, etc.), all objects have an identity, yet their internal structure can be inspected from any part of the program.

“The object need not expose its internal structure.”

Encapsulation a property of abstract data types (as in, for example, Standard ML), not objects. In some languages, like Java and C++, classes serve a hybrid role between abstract data types and objects, providing some of the encapsulation of the former (usually imperfect, since it can be bypassed using RTTI) and some of the dynamism (late binding) of the latter.

Eduardo León (talk) 15:54, 26 August 2016 (UTC)