Hi Daniel, >>> But then we lose the immutability of the built object, which was the >>> point of using builders on the first place. >> >> Ah, you're totally right! If builder is able to update an immutable >> object, then the object turns out to be mutable indirectly through the >> builder. I missed that part. :-) >> Hmm.. it seems difficult to make it immutable considering those >> expensive nested objects. >> Would it be possible to introduce lifecycle methods such as >> #initialize() in Configuration to prohibit (IllegalStateException) >> using it and its nested objects until initialized? > > Sure, but that was plan B in case we don't go for builders at all (see > in the thread starter mail). I mean, if we have that, what's the > benefit of the builder classes? When I go for builders, I would hope > fore real final fields in the built objects, and that also means that > I don't have to worry about the ordering of the field assignments, > because I got all everything at once, so I can sort the assignments.
Final fields for built objects is not a requirement if all the standard configuration settings are simple, e.g. String or Integer etc. Then possible mutations do not affect the standard configuration when using a builder. — Denis. >> If so, perhaps we can wait for everything configured in each stage >> and finally initialize those expensive objects only once by the >> core. Also, would it be possible to wait until the final >> initialization phase, only capturing settings, without having to >> create a nested object such as ObjecrWrapper in earlier stage? > > Where do I capture the settings of the ObjectWrapper (the nested > settings)? Anyway, that's why I thought that perhaps, if we have > cfg.setFoo(T) where Foo is not just some primitive or such, then we > also allow cfg.setFooBuilder(Builder<? extends T>)... and then, you > can, using your words, capture the nested settings too.
