-
-
Notifications
You must be signed in to change notification settings - Fork 779
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
Add support for fallback property #3675
Conversation
6255a2a
to
7526a32
Compare
Codecov Report
@@ Coverage Diff @@
## main #3675 +/- ##
============================================
+ Coverage 78.04% 78.05% +0.01%
- Complexity 2883 2891 +8
============================================
Files 473 473
Lines 9300 9329 +29
Branches 1767 1785 +18
============================================
+ Hits 7258 7282 +24
+ Misses 1078 1076 -2
- Partials 964 971 +7
Continue to review full report at Codecov.
|
detekt-api/src/main/kotlin/io/gitlab/arturbosch/detekt/api/internal/ConfigProperty.kt
Outdated
Show resolved
Hide resolved
SimpleConfigProperty(defaultValue) | ||
|
||
fun <T : Any> fallbackConfig(fallbackProperty: String, defaultValue: T): ReadOnlyProperty<ConfigAware, T> = |
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.
A wild idea: Could we use ReadOnlyProperty<ConfigAware, T>
as the type of fallbackProperty
? This can help us guarantee that there is no typo to be made as String
.
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 played around with this idea, but I don't see how that would be possible. The concern of having a typo is very valid IMO so I added a check in the config collector.
233fc73
to
7eee539
Compare
7eee539
to
385cf59
Compare
I came a bit late to the party but I have a couple of (maybe dumb) questions here:
|
I like the suggestion from @chao2zhang to give the each config delegate its own name so we don't just have the same function overloaded multiple times. When it comes to naming I am open for anything. I understand the reasoning and like your suggestion. What would you call the delegate that expects a List to be configured?
|
How about |
detekt-api/src/main/kotlin/io/gitlab/arturbosch/detekt/api/internal/ConfigProperty.kt
Outdated
Show resolved
Hide resolved
return checkNotNull(defaultArgument.getArgumentExpression()) | ||
} | ||
|
||
private object ConfigWithFallbackSupport { |
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.
Today I learned: We can define a non-companion object inside a class.
Why do we need |
I agree that the differenciation between |
If this is something we can agree on, I would clean up and add more tests. |
is Boolean, | ||
is Int, | ||
is Long -> configAware.valueOrDefault(propertyName, defaultValue) | ||
else -> error("${defaultValue.javaClass} is not supported as ") |
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.
Maybe using the code from here: #3676 (comment) we could make this more type safe.
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 problem here is, that fun <T : Any> config(defaultValue: T): ReadOnlyProperty<ConfigAware, T>
removes most of the type safety since a rule author could write val prop: Regex by config(Regex("aaa"))
which would compile but fail at runtime. With the code from this PR it is more explicit and we can provide a specific error message if the provided type is not supported.
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.
If we want that type of security (I agree with it). We could add a config file for each type. This way we ensure even more the type safety.
I think that the API looks nice :) |
This looks fine now. We can iterate later if we want. |
Is there anything I can do to help getting this merged? |
* Add support for fallback property * Introduce listConfig and fallbackConfig * Verify that the configured fallback property exists * replace config with listConfig where appropriate * rename fallbackConfig -> configWithFallback * rename parameter fallbackProperty -> fallbackPropertyName * Integrate configList into SimpleConfigProperty and FallbackConfigProperty * Improve error handling and add tests * Inline values to pass custom checks Co-authored-by: Markus Schwarz <post@markus-schwarz.net>
This PR relates to #3670 and adds support for annotated properties that have been renamed. Example:
without annotation
with annotation