If it isn't and you are concerned, then you can pass in a copy.
If it is, and you don't want that, you could pass in a copy.
And if it is immutable, I simply don't have to care. That's a benefit, because it reduces mental load while programming.
You're right. That was badly phrased and I apologise.
Apolgy accepted.
What you are implying, knowingly or not, is that every object should be immutable.
Not at all. There's a trade-off.
Because the alternative is a hybrid of mutable and immutable objects, that creates far more risk of forgetting to pass a copy when you need to ensure the original remains unmodified; or unnecessarily copying for the same reason.
That's not a big issue if you have a clear mental model about what a "value object" and what a mutable object is.
Again you're trying to argue that there's not sensible middle-ground, and I disagree.
I know of no language where everything is mutable, nor do I know languages where everything is immutable (in Haskell monads give you access to mutable storage).
Perl 5 is a good example: numbers are immutable, strings are not. That's a sensible tradeoff, but that doesn't mean there can't be other sensible tradeoffs.
In reply to Re^7: The fallacy of the *requirement* for read-only instance variables.
by moritz
in thread The fallacy of the *requirement* for read-only instance variables.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |