You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature
For a class Foo with a field bar of type Bar with constructor Bar(String a, int b) a @Builder today provides a method FooBuilder::bar(Bar bar) that takes an instance of a Bar.
This feature request proposes that in addition an "inline" builder method should be generated for any constructor of Bar, e.g. FooBuilder::bar(String a, int b).
Such Methods then take the constructor arguments of Bar and create an instance as part of their method body.
I'm scoping this feature request to fields that are records since I doubt it is feasible for classes (see below, additional context point 3), but I don't mind if it comes for ordinary classes as well.
Describe the target audience
Programmers that use @Builder on classes whose constructors take records as arguments, and these records are instantiated on the spot. They might be using Domain driven design (DDD) and thus not use primitives as their smallest building blocks but (record) classes. As a consequence the builder would take next to no primitives but mostly records, which makes for a lot of redundancy. E.g. in a Unit test a (school) class is created:
Additional context
One might argue against this feature by saying that:
A constructor should be used instead:
var expected = new Class(
new ClassName("9b")//year 9, student batch "b"
new Teacher("John", "Smith", 42)
new Animal("fido", "dog")
new Pupil("Alice", "Aberg")
new Pupil("Bob", "Bberg")
new Pupil("Carol", "Cberg")
);
There will be ambiguity, e.g. from self-referencing tree structures like record Tree(Tree subtree) because it is not clear if the tree that is passed should be assigned to the field or if it is rather a constructor argument. To avoid this the "inline methods" could simply have a suffix instead of overloading, e.g. fooFromArgs(...) or ideally something much shorter.
This cannot work for classes and their sub classes because there are too many, and some might be defined in a place that is not accessible at build time. => that's why I'm scoping this feature request to records since they can't inherit. Addressed here anyway for transparency.
I guess you could also decide to only generate inline builder methods for the class of the field and not allow constructors of sub classes. But that might come as a surprise to developers who don't read the fine print.
The text was updated successfully, but these errors were encountered:
Describe the feature
For a class
Foo
with a fieldbar
of typeBar
with constructorBar(String a, int b)
a@Builder
today provides a methodFooBuilder::bar(Bar bar)
that takes an instance of aBar
.This feature request proposes that in addition an "inline" builder method should be generated for any constructor of
Bar
, e.g.FooBuilder::bar(String a, int b)
.Such Methods then take the constructor arguments of
Bar
and create an instance as part of their method body.I'm scoping this feature request to fields that are records since I doubt it is feasible for classes (see below, additional context point 3), but I don't mind if it comes for ordinary classes as well.
Describe the target audience
Programmers that use
@Builder
on classes whose constructors take records as arguments, and these records are instantiated on the spot. They might be using Domain driven design (DDD) and thus not use primitives as their smallest building blocks but (record) classes. As a consequence the builder would take next to no primitives but mostly records, which makes for a lot of redundancy. E.g. in a Unit test a (school) class is created:Instead they want to write the more concise:
Additional context
One might argue against this feature by saying that:
record Tree(Tree subtree)
because it is not clear if the tree that is passed should be assigned to the field or if it is rather a constructor argument. To avoid this the "inline methods" could simply have a suffix instead of overloading, e.g.fooFromArgs(...)
or ideally something much shorter.I guess you could also decide to only generate inline builder methods for the class of the field and not allow constructors of sub classes. But that might come as a surprise to developers who don't read the fine print.
The text was updated successfully, but these errors were encountered: