Okay then, I'll bite. Assume I have the values `ace` and `spades`, with
which I construct my new immutable card:
class Card {
public final Suit suit
public final CardValue value
public this(final Suit suit, final CardValue value) {
this.suit = suit
this.value = value
}
}
Card aceOfSpades = new Card(spades, ace)
Where are the uninitialised values being exposed?
On 12 October 2010 02:02, Ben Schulz <[email protected]> wrote:
>
> 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]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
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.
