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.
In reply to Re^6: The fallacy of the *requirement* for read-only instance variables.
by BrowserUk
in thread The fallacy of the *requirement* for read-only instance variables.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |