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

TimeTemplates: Introduce Duration.ofX templates #41

Merged
merged 7 commits into from
Apr 10, 2022

Conversation

Badbond
Copy link
Member

@Badbond Badbond commented Feb 18, 2022

Introduces templates for Duration.of(amount, ChronoUnit.X) to Duration.ofX(amount) applicable to nanos, millis, seconds, minutes, hours and days.

Duration.ofSeconds(amount) does have an overload to specify nanoAdjustment but AFAICS defaults to 0 in both before & after.

Added a single test to see if it also works with static imports (but if obviously redundant, we can remove it).

Fixed some grammar in underlying JavaDoc.

@Badbond Badbond requested a review from rickie February 18, 2022 17:14
@Badbond Badbond force-pushed the pdsoels/time-templates-duration-of branch from 4ecd48a to d813d5b Compare February 18, 2022 17:22
@Badbond Badbond force-pushed the pdsoels/time-templates-duration-of branch from d813d5b to 0b62344 Compare February 18, 2022 17:44
@Badbond Badbond requested a review from mussatto February 21, 2022 08:21
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.

PR looks good! 🚀

Left some small tips 😄.

@@ -310,8 +311,80 @@ Duration after() {
}
}

static final class DurationOfNanos {
Copy link
Member

Choose a reason for hiding this comment

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

Almost every template in this class has a Javadoc, let's add it to these templates as well :).

Perhaps something along the lines of (just a suggestion):
Prefer ... over more contrived alternatives.

Copy link
Member

Choose a reason for hiding this comment

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

The templates are now based on the metric precision, which makes perfect sense. When looking at the implementation(s) of the Duration.of{...}(amount); methods, they are ordered lexicographically.
Based on that + knowing that @Stephan202 is a fan of lexicographical ordering, we could change the sorting to be lexicographical as well 😄.

Copy link
Member Author

@Badbond Badbond Feb 22, 2022

Choose a reason for hiding this comment

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

Yeah couldn't get a nice description for docs. Also not sure if I'd agree with the term 'contrived'. Based on the LocalTimeMin template I went with more basic:
/** Prefer {@link Duration#ofNanos(long)} over alternative representations. */ (and similar). Open to suggestions.

Regarding ordering, the implementation is not entirely lexicographically ordered 😄 ofSeconds is not in the correct place and ofMillis should be before isMinutes. Also TimeTemplateTestInput#testZeroDuration() orders in time magnitude.

But I don't have a strong preference for order (go Rebel Alliance!) so ordered them lexicographical now instead of in order of time magnitude (insert joke about Yoda time here) as you prefer.

Copy link
Member

Choose a reason for hiding this comment

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

For contrived I think this definition fits the context better: created or arranged in a way that seems artificial and unrealistic..
Nevertheless, good suggestion, SGTM!

Other suggestion would be "more verbose examples/representation" as we now don't need ChronoUnit 😄.

Regarding ordering, the implementation is not entirely lexicographically ordered

Did only check the first four methods, which was not enough apparently 😄.

return Duration.of(1, ChronoUnit.DAYS);
}

Duration testDurationOfDaysStaticImport() {
Copy link
Member

Choose a reason for hiding this comment

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

As you already pointed out in the PR description, indeed we do not need the static import case. Refaster is smart enough to also match this, so we don't need to have a test for this 😄.

Copy link
Member

Choose a reason for hiding this comment

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

Useful to know: if we want to have multiple test cases for one Refaster template, we generally wrap these cases in an ImmutableSet.of(...) and return that. This way we have the test cases together in one single method.

Within this class there are other methods that do this. See for example:
ImmutableSet<Duration> testZeroDuration() {

As a result the tests are more concise and it is easier to see how a Refaster template is tested.

Copy link
Member Author

@Badbond Badbond Feb 22, 2022

Choose a reason for hiding this comment

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

Regarding the static import test, this is now removed as suggested. Therefore, also no grouping required.

@rickie
Copy link
Member

rickie commented Feb 23, 2022

Nice 🚀 !

Copy link
Contributor

@mussatto mussatto left a comment

Choose a reason for hiding this comment

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

LGTM :)

@rickie rickie changed the title Introduce new Time templates for Duration.of methods TimeTemplates: Introduce Duration.of templates Feb 24, 2022
@rickie rickie changed the title TimeTemplates: Introduce Duration.of templates TimeTemplates: Introduce Duration.ofX templates Feb 24, 2022
@rickie
Copy link
Member

rickie commented Feb 24, 2022

Suggested commit message:

TimeTemplates: Rewrite `Duration.of(n, ChronoUnit.X)` to `Duration.ofX(n)`

Add templates for: `Duration.of{Nanos,Millis,Seconds,Minutes,Hours,Days}(n)`. 

@Badbond
Copy link
Member Author

Badbond commented Feb 24, 2022

Updated the commit message to have X recurring in both LHS and RHS.

Copy link
Member

@werli werli left a comment

Choose a reason for hiding this comment

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

Nice to see these getting added. 💪

Comment on lines +120 to +143
Duration testDurationOfDays() {
return Duration.ofDays(1);
}

Duration testDurationOfHours() {
return Duration.ofHours(1);
}

Duration testDurationOfMillis() {
return Duration.ofMillis(1);
}

Duration testDurationOfMinutes() {
return Duration.ofMinutes(1);
}

Duration testDurationOfNanos() {
return Duration.ofNanos(1);
}

Duration testDurationOfSeconds() {
return Duration.ofSeconds(1);
}

Copy link
Member

Choose a reason for hiding this comment

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

Interestingly, I'd have expected this to be sorted by time units (days, hours, minutes, seconds, millis, nanos), but this works for me as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

See discussion here. I'm open to both 😄

Copy link
Member

Choose a reason for hiding this comment

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

but this works for me as well.

Will keep true to my words here. 🙂

@rickie rickie requested a review from Stephan202 February 28, 2022 11:26
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.

Verified that the build also passes against master. Will merge with a slightly tweaked suggested commit message:

Prefer `Duration.ofX(n)` over `Duration.of(n, ChronoUnit.X)` (#41)

`TimeTemplates` now contains Refaster templates for 
`Duration.of{Nanos,Millis,Seconds,Minutes,Hours,Days}(n)`. 

@Stephan202 Stephan202 added this to the 0.1.0 milestone Apr 10, 2022
@Stephan202 Stephan202 merged commit 0d05106 into master Apr 10, 2022
@Stephan202 Stephan202 deleted the pdsoels/time-templates-duration-of branch April 10, 2022 14:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants