Immutability: > > Actually, immutability is complicated. For example, java.io.File seems > immutable for all intents and purposes, and has some of the practical > properties of immutables (such as: cloning a File object is pointless, > as is making a defensive copy), and certainly looks like one (only > final fields, and the class is even final itself), and you can even > share them between threads without synchronization, but nevertheless > it clearly looks like a mutable: Something like .mkdir() or .delete() > changes some state (it's just not state in the object that you're > changing!), and something like .isFile() is not predictable (i.e. it > can change over time, which is a property of mutables).
You're mixing up concepts here, taking the simple thing (immutability) and declaring it to be complicated because it's associated with another thing that truly *is* complicated (the Java standard I/O APIs). Immutability is simple. The Ace of spades is immutable, it will always continue to be the Ace of Spades into eternity. The same goes for April 12th 1942, or for the concept of "the file located at c:/autoxec.bat". Simple unchangeable concepts that can be readily passed around in the sure knowledge that they'll never magically become something else. The Java API however is *not* simple... java.io.File represents two totally distinct things! On one hand, it represents the concept of "the path to a file/directory". This is immutable, and quite safe. On the other hand, it represents "a bunch of side-effectful stuff that can be done against a file system" If there were two distinct classes for these two distinct ideas: FileRef and Filesystem, then the problem would go away. Methods like File.isDirectory() would become Filesystem.isDirectory(FileRef) and methods like getCanonicalFile would simply be a mapping from one (immutable) FileRef to another. > Similar issues exist for read-only wrappers around mutable lists. Are > these 'immutable'? Absolutely they are not! An "unmodifiable" collection is just a proxy to some other collection, with all the mutating methods redefined to throw an exception. I can create a List, wrap it with Collections. unmodifiableList(), then mutate the original. Guess what? My "unmodifiable" list has just been modified... Epic Fail! It's not a problem with the idea of immutability, just with the Java standard API. This is why Google Collections had to build their own. > jsr305 has a definition for this, which is focused around > the notion of never being able to see any of an object's state change. > However, the definition itself as given in the current javadoc is > broken; it means that an object that is capable of changing another > object, but is NOT capable of telling you this happened, is immutable. > Such an object is not thread-safe, but the javadoc says that any > immutable is necessarily thread-safe. Hence: broken. It's clearly far > too complicated to include now, given the small window of time to > investigate. > Agreed, it's a fundamentally flawed definition. If an object has methods that exhibit side-effects, then it isn't truly immutable. (although, notably, exceptions are *sometimes* permitted for caching and logging) Can we go back to a nice calming discussion on the use of Option/Maybe instead of nullability now please? My brain started to melt round about @EitherNullability -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
