你期望不可变列表的不变性有多深？

Question

If you have an immutable list, you expect it to always return a reference to the same object when you ask for, say

list.get(0)

My question is, would you expect to be able to mutate the object and have the mutation reflected next time you get it from the list?

Answer 1

It depends on the context. In a general purpose library, all we should assume is that the list is immutable. Changes to the elements in the list would be reflected to all callers, as a direct consequence of returning the same reference each time.

However, if this is a specialized immutable tree (or whatever), and is documented as such then you would expect the items in the list to themselves be immutable, and it becomes a moot question.

Answer 2

The question if not about the immutability of the list, but about the immutability of the objects contained.

In fact, if you have reference types, the immutable entity in the list is the reference. This means that the reference will always be the same. Now whether the referenced object changes only depends on what kind of object it is. If the object is immutable (like, for instance, strings in both .NET and Java, or all value types in .NET), the object cannot change.

Otherwise, the object can change and all other references to the same object will see the changed state, since they hold a reference to the same instance. Therefore, as I wrote in the beginning, this is completely independent of the list (and whether it is immutable or not).

Answer 3

Suppose a repair shop wanted to keep a permanent append-only record of all the cars that had ever visited, so that as each car entered the owners could find out if it had been in the shop before. Which would be better:

1. Keep a permanent record of the VIN (Vehicle Identification Number) of each car
2. Make a duplicate of each car (which, because VINs must be unique, must have a different VIN from the original) and permanently store the duplicate cars.

Note that a car itself is a mutable object, but the identity of a car, expressed by the VIN, is immutable. It's entirely possible that a car which was blue when it visited the shop has since been painted red. Thus, even if one had the ability to easily locate any car given its VIN, a list of cars (VINs) and when they were in the shop would not allow one to determine eg how many blue cars were serviced last Thursday. On the other hand, if the purpose of the list is to let one know whether an incoming vehicle had been in the shop previously, the list of VINs is exactly what one would need. If instead of having the VINs, one had a collection of duplicate cars, then not only would the cost of creating and storing all those duplicate cars be far greater than the cost of storing the VINs, but the collection would be almost useless for the stated purpose (determining whether a particular car had visited previously).

Answer 4

That's usually to be expected. The list is immutable, which means you cannot add or remove items in it or replace items entirely. If you want those items to be immutable you have to take care of that yourself. The list certainly can't stop you from mutating the object's state once you got a reference to it.

Answer 5

Yes.

I don't expect an immutable list to clone its objects when I get them, unless it is documented as doing so.

Answer 6

It really depends on the context in which you ask that question. Any experienced Java or C# developer knows that it's technically almost impossible to have a general "deep immutability" and therefore would not expect this. In C++, it's a very complex topic , so most developers probably also don't expect a dependable deep immutability. The D programming language, on the other hand, does have a language-level concept of transitive immutability, so a D programmer would probably expect it wherever it makes sense (which is quite often).

Answer 7

Yes, knowing Java, for an "immutable" List<T> I wouldn't expect T to be immutable unless T was immutable. However, a reasonable implementation of, say, List<Date> would be to copy the Date each time. The problem is that Date is mutable and can be distinguished from other equal Date s.