-
Notifications
You must be signed in to change notification settings - Fork 772
Add Builder/Creator/Updater for GHLabel #724
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
Conversation
|
|
||
| t = r.getLabel("test"); | ||
| t.setDescription("this is also a test"); | ||
| GHLabel t3 = t.set().description("this is also a test"); |
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.
Single Update
|
|
||
| // update works on multiple changes in one call | ||
| // t.setColor(""); | ||
| t2 = t.update().color("000000").description("It is dark!").done(); |
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.
Batch update
| return root.createRequest() | ||
| .withUrlPath(getApiTailUrl("labels")) | ||
| .toIterable(GHLabel[].class, item -> item.wrapUp(this)); | ||
| return GHLabel.readAll(this); |
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.
Moved all the calls that create instances of GHLabel into that class.
|
Overall I like the idea because of the ability to batch changes together. The api looks very intuitive. The base class is a little confusing for people intending to create a new API but it looks as simple as it can be while providing the benefit of reusability across the project. |
6ea9e4c to
9111081
Compare
| return description; | ||
| } | ||
|
|
||
| GHLabel wrapUp(GHRepository repo) { |
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.
Replaced wrapUp() with lateBind().
Update: removed need for late bind.
| * if there is an I/O Exception | ||
| */ | ||
| @Nonnull | ||
| public R done() throws IOException { |
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.
Any suggestions for a better method name than done()? send()? submit()?
We can't use commit() because it will almost surely collide with a git "commit" at least conceptually if not literally.
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.
BulkChange in core uses commit and abort. abort is not needed. Maybe send is a good choice. or call?
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.
The two places this will get used look something like this:
GHLabel label = GHLabel.create().name(name).color(color).description(description).xxxx();
label.update().color(color2).description(description2).xxxx();send() could work. call not as much. I'd just like to make sure we've considered alternatives before releasing this.
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.
Okay, well, this api is internal, so changing it later is not a breaking API change. I'll go with the current verbs for now and we can change them later if needed.
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.
Hm, doh, no, what was I thinking this is public. Ah, but I can use the same structure we already have for API Previews and ship this now. 😄There we go.
53e9da9 to
0b46ce0
Compare
5d4da2e to
208ffac
Compare
7c1be13 to
fb50ade
Compare
The guts of this version are a bit ugly but they result reasonable API code without a ton of extra code needed.
This removes the from the fields. Functionally the behavior is unchanged but it is no longer guaranteed at compile time. This simplifies streamlines the code slightly, but at the cost of only being able to assert immutability rather than know it. However, as we move to using this structure through more of the library, this is may be a better choice. There are so many places where the GitHub API itself returns partial records or updates them dynamically. Trying to claim immutability where it doesn't exist is not great either.
It turns out GHLabel instances do not need a reference to their repo, just to root.
29019d4 to
b823d68
Compare
b823d68 to
772272f
Compare
#724 broke the site goal from .github/PULL_REQUEST_TEMPLATE.md
Here's another possible way to address #589 . This PR uses
GHLabelas an example.@rmetzger @halkeye @PauloMigAlmeida @recena @res0nance - There's still a bunch to be done here (
sitecurrently fails due to missing JavaDocs for example), but if you look at the changes to the tests you can see what this new syntax will look like. My intent is to create a pattern that can be used consistently across the project. What do you think of this design?Highlights:
GHLabel, new instance creation does too (though in other classes creation may diverge more). "update-in-place" vs "update-to-new-instance" behavior actually identical except for oneif-elsein the the base class. This means that we can get this added functionality without significant added complexity.Technical notes:
finalto guarantee immutability but decided against it - While guaranteeing immutability viafinalfields sounds great, it results in a lot of extra code to make it work with Jackson in a way that the compiler doesn't choke on.