-
Notifications
You must be signed in to change notification settings - Fork 12
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 #460
Generate builder #460
Conversation
c3059f3
to
a72de0c
Compare
builder | ||
.setInt(1) | ||
.setRequiredString("two") | ||
.setOptionalString(null) | ||
.setOptionalString("three") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if we should let the builder die, and instead focus on mutable mirrors of the immutable types with some nice functions. Things like val user: User = User.build { .. }
plus relying on Kotlin scoping functions like .apply { }
as you're doing below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're referring to the factory function which I hadn't added yet at the time I opened this? But that doesn't require dropping the builder setters so maybe you mean something more substantially different.
In any case I'm closing this in favor of bnorm/piecemeal which was already way ahead of me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think generating builders are really a good idea. I would prefer to see the ability to generate mutable versions of the main poko type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a few obvious differences (class name, this
-returning setters) and a lot of similarities between the two. What's the important distinction that makes one a good idea and the other one not so good?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A builder works around Java language deficiencies, and Kotlin doesn't need those workarounds. We don't need named functions because we have named arguments and named properties. We don't need chaining because we have .apply
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I think we're on the same page then. I'll see if Brian will consider turning the setter functions off by default in piecemeal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I think what you're trying to build here already exists: https://github.com/bnorm/piecemeal |
IR layer not working yet.
IR body not generated yet.
a72de0c
to
5fc5d91
Compare
Noted, thanks for pointing that out. I reached out to Brian and I likely won't merge this if he plans to release that. |
Closing this in favor of bnorm/piecemeal. Once that's released I'll add tests to ensure Poko and piecemeal work well together. |
Closes #304.
Uses FIR declaration generation to create a nested Builder class to classes annotated with
@PokoBuilder
.To-do:
@Poko
annotation