Suggestion: protected constructor on builder
jedvardsson opened this issue · comments
Hi, I appreciate all you work on this project. Thank you.
What do you think about generating abstract builder classes (similar to AutoValue). This would allow for greater flexibility to add convenience methods and implement other interfaces? Like so,
@RecordBuilder
public record Example(String name) {
public static CatalogBuilder newBuilder() {
return new Builder();
}
public static final class Builder extends ExampleBuilder implement OtherStuff {
}
}
The only thing needed for this is that the generated builder's constructor isn't private right?
Yes, I suppose so. However, the newBuilder-method on the builder class will not work as expected. Therefore, to keep compatibility it might be better to make the generated builder abstract and add an abstract newBuilder-method, or leave it out entirely. Maybe new flag on the annotation abstractBuilder=true?
Yeah - I'm open to that if it's hidden behind an option as you suggest. My only concern is that it doesn't lock the library into anything for the future. Right now, for example, there are two private constructors. Other versions of the generated builder with other options generate constructors that are different. So, I wonder how tricky this will be to implement.
Maybe this isn't a good idea after all. Careless subclassing might messup equals and hashcode.
Agree - it might be a compromise to allow injecting super-interfaces that have default methods in it or something.
Yes, that is probably better.
I'm using the builders like this
@MyRecordBuilder
public record Costs(
@Nullable BigDecimal shipping,
@Nullable BigDecimal tax
)
{
public CostsBuilder toBuilder()
{
return CostsBuilder.builder(this);
}
public static CostsBuilder builder()
{
return CostsBuilder.builder();
}
}IMHO it's not that much more work to add these two methods.
@fprochazka, we are not talking about the “factory” methods which indeed are public already, but the the private constructor which prevents subclassing. However, it might not be a good idea after allow that.
Anyway, thanks for trying to help out. 👍
Yeah, I got that, I was just wondering why you'd want to subclass it?
Those who want to leverage the Builder as a parent class for a Java Bean.
See #128.
any plans to add support like this? i would love a good way to customize the builder. i've often wanted to add convenience methods to the builder. for example, i often use records for collections of options. there may be a common collection of options and i'd love to be able to add a convenience method like:
public Builder commonOptions() {
option1();
option2();
option3();
return this;
}
At this point I'd like to limit any new customizations. This library ran into a lot of problems with some of the recently added customizations.
The latest release has an option to make the ctors public