-
Notifications
You must be signed in to change notification settings - Fork 39
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
Introduce Refaster rules to streamline java.time
type creation
#322
Conversation
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.
Thanks for the PR, @CoolTomatos! I can you share some further details on why he "fluent" expressions should be preferred? (If helpful, feel free to reach out on Slack to link to an associated internal discussion.)
|
||
@AfterTemplate | ||
LocalDate after(Instant instant, ZoneOffset zoneOffset) { | ||
return instant.atOffset(zoneOffset).toLocalDate(); |
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.
While this is more "OOP-y" than the original, I'm not yet convinced that these rewrites are an improvement:
- The old code better conveys intent (IMHO).
- The old code seems more efficient.
So I wonder: shouldn't we define these rules in the opposite direction?
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.
Hi @Stephan202,
The four templates I added here is to extend the existing InstantAtOffset
(which I renamed).
I don't have strong arguments about one way or another.
Cc @rickie
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 have no strong preference here to be honest. So let's do it the other way around then :).
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.
Doing it the other way around SGTM! (I think that the existing OffsetDateTime.ofInstant(instant, zoneOffset)
-> instant.atOffset(zoneOffset)
makes sense, but for the new cases the static factory method seems to be the way to go 👍.)
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.
4478615
to
413ef61
Compare
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.
Added a commit. I suspect we may need to tweak the @BeforeTemplate
s a bit, but need to leave the metro now. More later (after a bunch of meetings).
error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/TimeRules.java
Outdated
Show resolved
Hide resolved
bbd1efb
to
b8af367
Compare
b8af367
to
36b5c80
Compare
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.
Rebased and added a commit. Nice set of rules like this!
Suggested commit message:
Introduce Refaster rules for canonical `java.time` type creation (#322)
(Not yet really happy with this suggestion; ideas welcome.)
LocalDate before(Instant instant, ZoneId zoneId) { | ||
return Refaster.anyOf( | ||
instant.atZone(zoneId).toLocalDate(), | ||
instant.atZone(zoneId).toOffsetDateTime().toLocalDate(), |
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.
We can have a separate instant.atZone(zoneId).toOffsetDateTime()
-> OffsetDateTime.ofInstant(instant, zoneId)
rule :)
static final class LocalTimeOfInstant { | ||
@BeforeTemplate | ||
LocalTime before(Instant instant, ZoneId zoneId) { | ||
return Refaster.anyOf( | ||
instant.atZone(zoneId).toLocalTime(), | ||
instant.atZone(zoneId).toOffsetDateTime().toLocalTime(), | ||
LocalDateTime.ofInstant(instant, zoneId).toLocalTime()); | ||
} |
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.
One could also go via OffsetTime
; will add.
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.
One question, other than that, LGTM!
Nice PR @CoolTomatos 🚀 !
error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/TimeRules.java
Outdated
Show resolved
Hide resolved
@chamil-prabodha anything from your side :)? |
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.
Looks good to me. I added one small comment in the tests.
Nice PR! This would definitely help us a lot to clean up the code 😄
...rone-contrib/src/test/resources/tech/picnic/errorprone/refasterrules/TimeRulesTestInput.java
Outdated
Show resolved
Hide resolved
36b5c80
to
3712722
Compare
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.
And rebased. :)
error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/TimeRules.java
Outdated
Show resolved
Hide resolved
3712722
to
5191427
Compare
I can only come up with: (I'm using ' in the examples to not break the Anyway, if you don't like the suggestion, I'd suggest to roll with the proposed one. @CoolTomatos thanks for the extra rebase 😉. |
I don't have merge rights so please go ahead with your suggestion captain @rickie 😁 |
So either:
I guess I'm still tending to the first option. Hard to put my finger on it, but it seems to make a more modest claim 🤔. Regardless: @rickie will let you merge :) |
Hehe it that case I'm going with the second one 👀:smile:. |
java.time
type creation
No description provided.