Sunday, February 19, 2017, 11:35:44 AM, Denis Bredelet wrote: > My message was not clear, I mean builders are not required for > standard configuration settings if they are simple types.
Of course not. We are only talking about setting values like ObjectWrapper, TemplateLoader, TemplateResolver (when it's added), etc. For them, I think we will have just bite the bullet and add both `void setFoo(Foo)`, and `void setFooBuilder(Builder<Foo>)` (and their fluent API equivalent), and `Builder<Foo> getFooBuilder()`, but no Foo getFoo(). And if you call setFoo(myFoo), then getFooBuilder() will return something like a `new o.a.f.core.ResultWrapperBuilder(myFoo)`, where ResultWrapperBuilder is just a wrapper myFoo, so that it satisfies the Builder<Foo> interface. I think I will also ban using setFoo(Foo) if Foo is known to have a Builder, just to enforce the intended usage pattern. Unless somebody comes up with a better idea, I will try this approach when I get there, and we will see how it works out in reality. >> Le 19 févr. 2017 à 10:24, Denis Bredelet <[email protected]> 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. >> > > -- Thanks, Daniel Dekany
