My message was not clear, I mean builders are not required for standard configuration settings if they are simple types.
> Le 19 févr. 2017 à 10:24, Denis Bredelet <brede...@mac.com> a écrit : > > 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. >
