different libraries where you don't know how well they are programmed

Hm. So, you make your date object immutable so that you can safely pass it to library code that you didn't write and know it will not be modified.

Except that, for the library to accept this data object, it has to be programmed to expect this type of date object or one compatible with it. And if it mutates it, then that should be documented.

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.

If it isn't and it does, then that is a bug.

Again, you are forcing objects to be copied when they needn't be, in order to avoid having to when know you should.

Please stop laying words in my mouth that I didn't utter.

You're right. That was badly phrased and I apologise.

I should have said: What you are implying, knowingly or not, is that every object should be immutable.

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.

Which essentially negates the only benefit: that of not having to copy when you are unsure. That does not seem tenable to me.

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.

Perl 6 - second systems done right

And if it is immutable, I simply don't have to care. That's a benefit, because it reduces mental load while programming.

Sorry, but that simply isn't true. There is no reduction in cognitive load in a hybrid environment, because you still have to think about which type you are dealing with every time.

That's not a big issue if you have a clear mental model about what a "value object" and what a mutable object is.

A clear mental model huh.

Perl 5 is a good example: numbers are immutable,

Really?

$i = 1; 
++$i; 
print $i;;
2
[download]

Okay. Bye.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

In C++, I can declare a date that can be mutated, or a const date which is immutable. And I can convert the first to the second, or copy the second into the first.