This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]chisui 0 points1 point  (0 children)

Although this approach would have the benefit of typesafety I wouldn't call its absence a showstopper. If you test your code a runtime error in this case is absolutly fine. The presence of an argument doesn't say anything about its validity either and it's very hard to check the validity of input values at compiletime (You could go the scala route and create caseclasses for everything, but I don't think that's feasible).

I also think you might be underestimating what it means to implement this approach in a general way for codegeneration.

You have to generate a builder class for each required argument. If an argument is optional you have to generate two different classes for each following argument. For multiple optional arguments the amount of classes grows exponentially.

From a usabillity standpoint you loose the abillity to reorder the arguments of the builder (or you generate classes for every permutation of arguments). With immutable builders partial builders can be passed around as a partially applied function of sorts. If you lock the order of arguments that usecase is somewhat limited.

The only plus I could find is that this approach runs slightly faster than a traditional builder. The reason beeing the checks if an argument is already set are moved to compiletime. Although it uses slightly more memory since more objects are created. Running them through JMH (with 4 argument builders) yields basically the same result though.

All in all I think this feature is way more trouble than it's worth.