> On 25 Sep 2017, at 03:36, Stephen Colebourne <scolebou...@joda.org> wrote: > > What we really need however is immutability as a language feature, > where an immutable collection can be an interface, and it can assert > that only other immutable classes can be contained. Since we are a > long way from this,
Yes, and even a long way from getting immutable collections that make no guarantees on the mutability of their elements. (Note that even if immutable collections exist there is a notion of building up such a collection mutably in a confined manner after which it is frozen and published in its immutable form.) > it seems reasonable to make the change outlined in > the webrev. It also seems reasonable to use the term "unmodifiable" > not "immutable" to leave "immutable free for the future. > +1 I was gonna say much the same thing. The notion of unmodifiable can be improved independently of anything that may be done in the future regarding immutable collections (including say persistent collections). Improving the “old” mutable world is still beneficial even if there will be some future “new” immutable collection world (independent of the mutability of the elements) as we will need bridges between the two. Pail.
