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.
> 

Reply via email to