On 12 October 2010 00:43, Miroslav Pokorny <[email protected]>wrote:
> > On Tue, Oct 12, 2010 at 10:22 AM, Kevin Wright > <[email protected]>wrote: > >> >> >> 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. >> >> Attempting to define anannotation that the compiler can somehow verify is > dumb because immutability is concept that exists at higher level that a > compiler can never fully appreicate or understand. At best immutability can > only be a tag rather than actual verifiable construct. Imjutability is more > than just having all fields being final, in the end when one gets away from > more toy examples what exactly can it verify. If you want to document > something as immutable then write some real javadoc. Personally i think all > these discussions are kind of pointless, when we would do better if people > just spent the time writing up some proper javadoc. > > The immutable annotation is intended for humans to read, for static analysis tools and, yes, for Javadoc generation. I doubt we could ever see compiler-enforced immutability in Java, it would first require a wholesale shift toward embracing referential transparency in the design of Java APIs I'd love to see this happen, and believe it will on the Java platform, if not the Java language. In the meantime, we'll continue to struggle with libraries that are built on side-effects and need copious Javadoc simply to understand what they're actually doing (e.g. Spring) -- 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.
