On 12 Okt., 02:33, Kevin Wright <[email protected]> wrote: > > But when did it begin being the ace of spades? Unless all fields keep > > their initial value any object changes; the ace of spades began its > > life as the null of null. > > immutable, not immortal. > > At some point in the past it came into being through the union of "Ace" and > "Spades". > Before Spades we had tarot decks, with swords on. They still exist. > > I'm fully aware of the distinction between "Ace of Spades" as a purely human > concept and "Ace of Spades" as constructed on the heap. And yes, at some > point in time during that construction there started out a bunch of memory > that was initially set to zero. But that's an underlying detail of the JVM > implementation, not some aspect of the domain model. Sure it's a > interesting topic, but not quite relevant in a discussion on the *concept* > of immutability.
But it's not an implementation detail, I can observe the uninitialized value and thus I can observe two different states of a supposedly immutable object. Is that not contrary to the *concept* of immutability? > > No a big deal because nobody can observe > > this state, however, once one gets into initializing immutable object > > graphs things get very hairy very quickly: Immutability is not that > > simple after all. > > But, crucially, the swords on all existing tarot decks didn't suddenly > become spades once that suit had been devised. They remained swords, > stubbornly and immutably. > I can only imagine that this convenient fact rather simplified the lives of > fortune tellers! > > The question is: What's inherently more complicated about the > initialisation of an object when it has final fields? Is there some > particular problem you have with JodaTime that's perhaps causing you to tear > your hair out? > > This issue also neatly demonstrates why Option/Maybe won't magically get rid > > > of null. > > Okay, so what if the underlying architecture must necessarily have > uninitialised values at some point? Why does that mean a higher-level > language such as Java must expose these? After all, the underlying > architecture quite clearly has function pointers... Because there is a conceptual difference between uninitialzed (null) and None. If a developer assumes the initial value will never be read, but in reality overlooked a code path which is executed once in a blue moon, I'd rather it blow up with an NPE. I want to consciously decide that reading None in that scenario is correct and explicitly initialize it. With kind regards Ben > -- > 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.
