-
Notifications
You must be signed in to change notification settings - Fork 175
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
Fix #340 #641
Merged
Merged
Fix #340 #641
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
80d289f
Modified the name of isGetter to be changed by findImplicitPropertyName
k163377 e99ea39
Modify fixed test case and move package
k163377 24e2968
Added test case for when PropertyNamingStrategy is specified
k163377 8ada33f
Added test case for isSetter to work.
k163377 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Ok: I think you should ONLY need to consider
isXxx()
case, given thatgetXxx()
should work by default.The intent of "implicit name" was originally to allow exposing names for constructor parameters, because names were not included in byte code, unlike with methods and fields. So if there is no addition "implicit" name, underlying method/field name is used. It seems better (at least conceptually) to only override cases where there is difference.
Otherwise, I think that use of implicit name route may be better than rename using
findRenameByField
... if it works as well I see no reason for other case.However: use of
findRenameByField()
may make sense for a different case: case where property name starts with capital letter. Intent with this method is that instead of starting with getters, setters and fields all to unify names, instead start with field name. This tends to work better for Kotlin, Scala etc where developers specify property name as "plain", similar to it being field (and in fact being added asField
) and getter/setter name is created based on that.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.
This branching only applies when the getter name contains
-
, so I believe the behavior is as you say.The reason for this is as per the comments on lines 39 and 40.
I don't see how using
findRenameByField
would avoid the problem (#340) of confusion when two properties,isFoo
andfoo
, are defined (this is the main problem I wanted to solve).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.
Ah. Ok, that
-
part I somehow missed although explicitly stated. Still, what I was trying to say is that I think you are right in preferring implicit name production overfindRenameByFiedl()
for cases you are thinking of solving.