3 ms·

Immutability and Value Objects

3 points by sudhirj 15y ago

zeeed 15y ago
thanks for the posting. Quick feedback: you use "lX" as a variable name. That makes the code barely readable, because the letter l looks VERY similar to the number 1 in most systems. It might sound nitpicky but it does distract from the article.
- sudhirj 15y ago
  Thanks for the tip :) ... will make an update.
tinus 15y ago
More nitpicky feedback: assertEquals(oneMeter, tenCentimeters); Of course the code is not wrong per se, it will simply throw an exception, but it still made me frown. I wonder if you really meant to write this. Anyhow, this is a great article! I value the clear wording.
ExpiredLink 15y ago
Values are stateless and immutable, objects are stateful and mutable. Strictly speaking, the term 'Value Object' is an oxymoron. Unfortunately, in Java you can define values only in terms of classes and objects which leads to continuous confusion. The distinction between values and objects remains unclear for most Java developers.
- bunderbunder 15y ago
  In the first research forays into what became OOP, objects were conceived of as being immutable by definition. That quickly went by the wayside as it ran up against a number of practical hurdles. But even then, in earlier true OOP languages such as Smalltalk there was simply no distinction between values and objects. In classic OOP, everything is an object, period. Later on, languages such as C++ and Java muddied the waters (imo) by throwing their own distinctive interpretations of what it means to be object-oriented into the ring. One of these 'innovations' was the idea that values and objects are somehow distinct. This idea has nothing to do with OOP orthodoxy and, everything to do with C++ maintaining a strong semantic distinction between the procedural type system it inherited from C and the object-oriented type system it introduced. Java simply followed C++'s lead on that front, albeit unnecessarily since Java lacks the characteristic (linking with C binaries) that motivated that feature in C++. Thus, there was an incredibly popular language which advertised itself as object-oriented, but featured wooly non-standard (for OOP) semantics for no apparent reason. Which naturally invites some retconning. Hence the idea that the concept of objects is anything but purely orthogonal to the distinction between value and reference semantics. Without such stories, one is stuck with the more historical story that a central, but often obnoxious and confusing (for learners, at least) feature of the two most popular languages in current usage is simply a hack in one case, and a foolish consistency in the other.

3 points by sudhirj 15y ago

zeeed 15y ago

thanks for the posting. Quick feedback: you use "lX" as a variable name. That makes the code barely readable, because the letter l looks VERY similar to the number 1 in most systems. It might sound nitpicky but it does distract from the article.

sudhirj 15y ago
Thanks for the tip :) ... will make an update.

tinus 15y ago

More nitpicky feedback: assertEquals(oneMeter, tenCentimeters); Of course the code is not wrong per se, it will simply throw an exception, but it still made me frown. I wonder if you really meant to write this. Anyhow, this is a great article! I value the clear wording.

ExpiredLink 15y ago

Values are stateless and immutable, objects are stateful and mutable. Strictly speaking, the term 'Value Object' is an oxymoron. Unfortunately, in Java you can define values only in terms of classes and objects which leads to continuous confusion. The distinction between values and objects remains unclear for most Java developers.

bunderbunder 15y ago
In the first research forays into what became OOP, objects were conceived of as being immutable by definition. That quickly went by the wayside as it ran up against a number of practical hurdles. But even then, in earlier true OOP languages such as Smalltalk there was simply no distinction between values and objects. In classic OOP, everything is an object, period. Later on, languages such as C++ and Java muddied the waters (imo) by throwing their own distinctive interpretations of what it means to be object-oriented into the ring. One of these 'innovations' was the idea that values and objects are somehow distinct. This idea has nothing to do with OOP orthodoxy and, everything to do with C++ maintaining a strong semantic distinction between the procedural type system it inherited from C and the object-oriented type system it introduced. Java simply followed C++'s lead on that front, albeit unnecessarily since Java lacks the characteristic (linking with C binaries) that motivated that feature in C++. Thus, there was an incredibly popular language which advertised itself as object-oriented, but featured wooly non-standard (for OOP) semantics for no apparent reason. Which naturally invites some retconning. Hence the idea that the concept of objects is anything but purely orthogonal to the distinction between value and reference semantics. Without such stories, one is stuck with the more historical story that a central, but often obnoxious and confusing (for learners, at least) feature of the two most popular languages in current usage is simply a hack in one case, and a foolish consistency in the other.