Introduce ImmutableTableRules Refaster rule collection
#1489
Conversation
|
Looks good. No mutations were possible for these changes. |
|
Looks good. All 1 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
| @UseImportPolicy(STATIC_IMPORT_ALWAYS) | ||
| ImmutableTable<R, C, V> after(Stream<E> stream) { | ||
| return stream.collect( | ||
| toImmutableTable(e -> rowFunction(e), e -> columnFunction(e), e -> valueFunction(e))); |
There was a problem hiding this comment.
Can't these can be lambda expressions?
There was a problem hiding this comment.
You mean method references? 🙃
Unfortunately, Refaster doesn't have a "make this a method reference if possible" feature.
There was a problem hiding this comment.
You mean method references? 🙃
Yes, sorry 🙈
| private ImmutableTableRules() {} | ||
|
|
||
| /** Prefer {@link ImmutableTable#builder()} over the associated constructor. */ | ||
| // XXX: This rule may drop generic type information, leading to non-compilable code. |
There was a problem hiding this comment.
Technically it does not drop all generic type information, correct?
| // XXX: This rule may drop generic type information, leading to non-compilable code. | |
| // XXX: This rule may drop explicit generic type information, leading to non-compilable code. |
There was a problem hiding this comment.
Indeed, but it also says "may", so it's clear that anyway this is an issue only in a subset of cases. :)
| private ImmutableTableRules() {} | ||
|
|
||
| /** Prefer {@link ImmutableTable#builder()} over the associated constructor. */ | ||
| // XXX: This rule may drop generic type information, leading to non-compilable code. |
There was a problem hiding this comment.
Indeed, but it also says "may", so it's clear that anyway this is an issue only in a subset of cases. :)
| @UseImportPolicy(STATIC_IMPORT_ALWAYS) | ||
| ImmutableTable<R, C, V> after(Stream<E> stream) { | ||
| return stream.collect( | ||
| toImmutableTable(e -> rowFunction(e), e -> columnFunction(e), e -> valueFunction(e))); |
There was a problem hiding this comment.
You mean method references? 🙃
Unfortunately, Refaster doesn't have a "make this a method reference if possible" feature.
|
Validated that these changes do not impact the integration tests. |
| } | ||
|
|
||
| /** Prefer {@link ImmutableTable#of()} over more contrived alternatives . */ | ||
| static final class ImmutableTableOf<R, C, V> { |
There was a problem hiding this comment.
Would it make sense to move this Refaster rule a bit more up? Like right after the builder or the ImmutableTableBuilderBuildOrThrow one?
There was a problem hiding this comment.
I wondered the same, but modelled this after ImmutableMapRules 🤷. (If/when we decide to auto-sort rules, this kind of more semantic approach to ordering will likely go out the window. Something to consider.)
rickie
force-pushed
the
sschroevers/additional-immutable-table-rules
branch
from
3e9746d to
7d2a94d
Compare
|
Looks good. All 1 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Stephan202
force-pushed
the
sschroevers/additional-immutable-table-rules
branch
from
7d2a94d to
58dcc7d
Compare
|
|
Looks good. All 1 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Suggested commit message:
This work results from #1223 and this comment, with the observation that
ImmutableTablehas a distinct builder type. The rules introduced here are a subset of those defined byImmutableMapRules.