To be fair, if you're really going all the way with immutability then you'll also end up working with persistent data structures http://en.wikipedia.org/wiki/Persistent_data_structure - this is not "persistent" with the same meaning as e.g. hibernate)
These are always implemented as a directed acyclic graph and get built from the bottom up, so you never encounter the situation that an instance can't be initialised atomically. If you do have need of phased initialisation (compilers are a good example here), then it should be modelled as a set of transformations - each such transformation taking one immutable object and yielding another. This isn't just a case of objects appearing not to change, they really truly don't change after being atomically constructed. Incidentally, the JVM is heavily optimised for this sort of thing: a succession of short-lived objects, each representing a previous object with some transformation applied. Everything gets done in the "Eden Space" where garbage collection is extremely cheap. On 12 October 2010 15:20, Ben Schulz <[email protected]> wrote: > On 12 Okt., 11:19, Kevin Wright <[email protected]> wrote: > > Where are the uninitialised values being exposed? > > Let me quote my first response: > > No[t] a big deal because nobody can observe this state, however, once one > gets into initializing immutable object graphs things get very hairy very > quickly: > > It's not so much about what is exposed to library consumers, but > rather what the library developer can observe. Obviously an immutable > object should /appear/ to never change, but my whole point is that it > does anyway. And it's extremely difficult to prove that complex object > graphs (potentially containing multiple cycles) end up with all fields > correctly initialized. > > A classic example is phased initialization. First you create the > object graph, a set of objects V with arbitrary relationships between > elements of V. Then you establish invariant I_1 for all elements of V, > then invariant I_2, and so on and so forth until you reach I_n. At > that point all elements in V are in fully initialized. An example of > such object graphs is the Java type system: Only after you created all > types and their parameters can you initialize theirs supertypes (and > bounds respectively). > > interface I<T extends I<T>> {} > class A implements I<B> {} > class B extends A {} > > With kind regards > Ben > > -- > 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.
