Talk:Value object

Fixed the Java part removing the mistaken comment on Strings and Integers: it is only in function passing that a reference to a string if modified does not affect the original reference.

C# value types and the stack

The whole sentence The memory management is also different: the data of a struct in C# is kept in the stack while for classes the data is stored in the heap memory. This memory management can help in terms of performance. This does not happen when the value in question is wrapped inside another object, e.g. an array of some struct type, in which case the struct(s) will live, inside the object, on the heap.[7]

is inaccurate, redundant and vogue. There are plenty of cases when a value-type would be stored in the heap such as (but not limited to):

• value-type as a field of a class
• value-type as an element (or as field of such element) of an array
• boxed value-type (when stored as a reference to one of its base classes [ValueType/Enum or object], or to an implemented interface)
• parameter/variable which involved in a closure
• parameter/variable of a generator block
• parameter/variable of an async method

While the cases when the're stored on the stack are only implementation details irrelevant to the C# specification.

And the really sad thing, is that the cited reference talks exactly about how bad is this explanation.

Moreover - in C# everything (except unsafe pointers) is an object. A class (refernce-type) could be immutable (such as the string class). A struct could be mutable (although generally regarded as a bad idea).

The only difference is that the value of an expression of a type which is a value-type - is the data itself, while the value of an expression which is type is of reference-type, is a reference to the data, which is stored somewhere else. This is why value-types cannot be passed by reference by themselves. 84.228.163.42 (talk) 07:40, 17 August 2014 (UTC)

Oxymoron

It seems to me that the term “value object” is an oxymoron. The definitions of “value” and “object” impose mutually contradictory requirements, so nothing can be both a “value” and an “object” at the same time.

A value is the result of a finished computation. Its physical location and concrete representation don't matter. Two different computations might return the same value, yet store its representation in different locations. So multiple copies of the same value may exist in memory at any point in time. Furthermore, a single value may have more than one representation. For example, if ordered sets are represented as red-black trees, two different red-black trees (balanced differently) may represent the same ordered set.

On the other hand, an object is an abstract memory location. There is always exactly one copy (and thus exactly one representation) of each object in memory at any point in time. If there were two or more copies, each copy would have to be stored in a different memory location, contradicting the fact that they are copies of the same object.

Eduardo León (talk) 17:25, 26 August 2016 (UTC)

Usage of "entity" is confusing

The current definition seems confusing to me:

"In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object."

The definition of "entity" linked here says:

"In computer science, an entity is an object that has an identity, which is independent of the changes of its attributes. It represents long-lived information relevant for the users and is usually stored in a database."

--

In fact, an entity is usually considered to be the opposite of a value object from the equality perspective:

• a value object is an object whose equality is not based on identity
• an entity is an object whose equality is based on identity

So in my opinion a value object cannot be "a small object that represents a simple entity". NiValve (talk) 11:36, 18 January 2024 (UTC)