> In that case, you want values rather than objects.
In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".)
Conceptually (and ignoring the implementation details, which may have performance implications), immutable objects are equivalent to values, anyhow.
> Conceptually ... immutable objects are equivalent to values, anyhow.
Nope. Since values don't reside in computer memory other than through their representations, the language implementation (compiler, runtime system, etc.) is free to apply optimizations such as:
(0) Determine whether a value is represented more than once in memory, and eliminate the redundant representations.
(1) Store multiple values in a single dynamically allocated memory block.
If object identities matter, all of this is unsound.
> ... (and ignoring the implementation details, which may have performance implications), ...
The performance implications can be constrained by equipping the language with a cost semantics.
In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".)
Conceptually (and ignoring the implementation details, which may have performance implications), immutable objects are equivalent to values, anyhow.