Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate Builder with static compile-time safe checking of mandatory bean properties #370

Closed
vorburger opened this issue Aug 25, 2016 · 6 comments

Comments

@vorburger
Copy link
Member

Have you considered generating Builders which allow some nullable properties yet enforce the presence of all other mandatory (required) properties at compile time, instead of by exception at runtime by validation?

See https://github.com/vorburger/eclipse-null-eea-augments/blob/12a59e0dad053536bb1ac1beb25a23673b24eca2/examples/eclipse/hello/src/main/java/ch/vorburger/nulls/examples/hello/Person.java for a (hand-written, example) of the pattern I mean.

Note that the order of the mandatory properties has to be fixed in this approach of course, like with a constructor instead of Builder, but it's still much more readable than with a constructor, because property names are evident.

This kind of pattern is very verbose to hand-write due to one *Builder class per required property, but ideal for code generators, thus IMHO of possible interest to auto value?

@rharter
Copy link
Contributor

rharter commented Aug 25, 2016

One issue I see is that, while AutoValue can generate the backing implementation, the user still has to write the public facing API, which is the verbose part of this. So you'd still have to write abstract classes for the required property builders, which doesn't save you a lot.

@eamonnmcmanus
Copy link
Member

The idea is interesting. In fact, I have a vague recollection of some rather tricky use of generics that would mean you could even lift the requirement that properties need to be set in a particular order. (The generics keep track of which properties have been set.)

However, one of our core principles in AutoValue is that we don't ever generate APIs, we only implement APIs that the user has written. I'm not sure how to square that with compile-time checking of what properties have been set.

@vorburger
Copy link
Member Author

Apologies for not fully understanding AutoValue - given what you've explained above, this idea is probably not feasible / applicable here then. Please therefore feel free to close the issue if you like - no offence taken.

PS, FTR: I've proposed the same approach to immutables.org, as I gathered they are coming as this from a different angle and do generate APIs if I'm not completely mistaken, so it may be of interest there.

@androidfred
Copy link

IMO this would be a better style of implementation (as referenced on #385)

http://blog.crisp.se/2013/10/09/perlundholm/another-builder-pattern-for-java

@jbgi
Copy link

jbgi commented Oct 3, 2016

@androidfred, @vorburger this project implement the above style: https://github.com/h908714124/zerobuilder

@vorburger
Copy link
Member Author

FTR: @elucash over on http://immutables.org has now implemented immutables/immutables#438. FYI they call this style "Staged (aka telescopic) builders" over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants