Proposal: Deprecate Builders

[Tom Eugelink]

On 2013-04-04 06:17, Richard Bair wrote:
> No, I think this is OK on Java 8 and was an approach looked at (although we looked at it by having AbstractFooBuilder & FooBuilder at every level, rather than in the actual class hierarchy). It suffers as you say from excessive classes. The other thing that bothers me is having a setter that doesn't return void. That doesn't bother me in the general sense (it seems like a fine thing to do!) but from the perspective that it breaks the conventional definition of a bean setter, and so will run afoul of any existing JavaBeans tools which might, for example, explicitly check for a public void setFoo method for any given foo property to determine whether it is writable. Fitting in to the existing Java universe was an important design constraint.

The approach with the self() method removes the need for casting in the wither (withers are used to keep the setters return void), but it still requires leaf and branch nodes (Button extends AbstractButton<Button>). The question is whether having these classes is a bad or good trade-off vs keeping something similar to the builder functionality. For me personally that answer is easy. I do not care if the casting or self() pattern is used. BTW, I'm still planning to setup a test for the casting pattern as agreed, but currently am flushed with end-of-competition-season basketball activities.

Tom