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

Introduce Refaster rules to streamline java.time type creation #322

Merged
merged 5 commits into from
Nov 4, 2022

Conversation

CoolTomatos
Copy link
Contributor

No description provided.

Copy link
Member

@Stephan202 Stephan202 left a 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();
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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 :).

Copy link
Member

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 👍.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can do

@rickie rickie added this to the 0.6.0 milestone Oct 31, 2022
@CoolTomatos CoolTomatos force-pushed the CoolTomatos/instant_related_templates branch 5 times, most recently from 4478615 to 413ef61 Compare October 31, 2022 22:31
Copy link
Member

@Stephan202 Stephan202 left a 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 @BeforeTemplates a bit, but need to leave the metro now. More later (after a bunch of meetings).

@CoolTomatos CoolTomatos force-pushed the CoolTomatos/instant_related_templates branch from bbd1efb to b8af367 Compare November 1, 2022 19:04
@Stephan202 Stephan202 force-pushed the CoolTomatos/instant_related_templates branch from b8af367 to 36b5c80 Compare November 3, 2022 18:39
Copy link
Member

@Stephan202 Stephan202 left a 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(),
Copy link
Member

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 :)

Comment on lines 108 to 119
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());
}
Copy link
Member

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.

Copy link
Member

@rickie rickie left a 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 🚀 !

@rickie
Copy link
Member

rickie commented Nov 3, 2022

@chamil-prabodha anything from your side :)?

Copy link
Contributor

@chamil-prabodha chamil-prabodha left a 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 😄

@Stephan202 Stephan202 force-pushed the CoolTomatos/instant_related_templates branch from 36b5c80 to 3712722 Compare November 4, 2022 04:33
Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And rebased. :)

@CoolTomatos CoolTomatos force-pushed the CoolTomatos/instant_related_templates branch from 3712722 to 5191427 Compare November 4, 2022 11:36
@rickie
Copy link
Member

rickie commented Nov 4, 2022

I can only come up with: to streamline 'java.time' type creation.
Without looking at InstantAtZone, as it is an exception to the rule (or suggested commit message for that matter), it would make sense to call it something like ... prefer '#ofInstant' method for creating 'java.time' types.

(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 😉.

@CoolTomatos
Copy link
Contributor Author

CoolTomatos commented Nov 4, 2022

I don't have merge rights so please go ahead with your suggestion captain @rickie 😁

@Stephan202
Copy link
Member

So either:

  • Introduce Refaster rules for canonical `java.time` type creation (#322)
  • Introduce Refaster rules to streamline `java.time` type creation (#322)

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 :)

@rickie
Copy link
Member

rickie commented Nov 4, 2022

@rickie will let you merge :)

Hehe it that case I'm going with the second one 👀:smile:.

@rickie rickie changed the title Added templates to convert Instants to different Temporal classes in a more fluent way. Introduce Refaster rules to streamline java.time type creation Nov 4, 2022
@rickie rickie merged commit 281534a into master Nov 4, 2022
@rickie rickie deleted the CoolTomatos/instant_related_templates branch November 4, 2022 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants