Talk:Identity (object-oriented programming)
| This article was nominated for deletion on 1 February 2026. The result of the discussion was redirect. |
| This redirect does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
| |||||||||||
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:
- . Weasel word: often not useful. How often? To Whom?
- . Grammar: first sentence is a run-on which makes no sense.
- . 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)
- Well... I see your confusion, but at the same time it's true that identity is a property of an object. I guess your confusion stems from property being used in some languages to describe less fundamental aspects/attributes of an object such as custom fields. Even the words I used (aspect/attribute) are also fraught with confusion since some languages use them too. I agree that identity is more fundamental than other aspects/attributes. But, there are only so many words for the concept and they are all overloaded. What to do? Stevebroshar (talk) 12:02, 31 October 2024 (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)
- I think you are saying that identity is not related to the concept of black-box and internal structure. I agree. Identity has nothing to do with visibility. Stevebroshar (talk) 12:05, 31 October 2024 (UTC)
Content Disclaimer
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
- The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
- There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
- It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
- Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
- Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.