-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Record like property access support #2994
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
Conversation
| putInNegativeCache(cacheKey); | ||
| return null; | ||
| } | ||
| } |
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 unwound the nesting of the exceptions - there was no need for it and I think this is clearer code
| Records cannot extend any class - so we need only check the root class for a publicly declared method with the propertyName | ||
| */ | ||
| private Method findRecordMethod(CacheKey cacheKey, Class<?> rootClass, String methodName) throws NoSuchMethodException { | ||
| if (Modifier.isPublic(rootClass.getModifiers())) { |
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.
Records are also final. findRecordMethod should be restricted to records or other final classes.
if (Modifier.isPublic(rootClass.getModifiers()) && Modifier.isFinal(rootClass.getModifiers())) {
| * smells like one and that's enough really. Its public, not derived from another | ||
| * class and has a public method named after a property | ||
| */ | ||
| public class RecordLikeClass { |
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.
Make this public final class
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 have decided we will look up record like methods - not truly final ones like records are.
# Conflicts: # src/main/java/graphql/schema/PropertyFetchingImpl.java
| MethodFinder methodFinder = (rootClass, methodName) -> findRecordMethod(cacheKey, rootClass, methodName); | ||
| return getPropertyViaRecordMethod(object, propertyName, methodFinder, singleArgumentValue); | ||
| } catch (NoSuchMethodException ignored) { | ||
| } |
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 unwound the nesting because I think this reads better than try inside try inside try
| if (!recordLikeMethods.isEmpty()) { | ||
| return recordLikeMethods.get(0); | ||
| } | ||
| return null; |
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.
Support in the lambda code to find recordLike() methods
|
|
||
| public String recordLike() { | ||
| return "recordLike"; | ||
| } |
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.
IN theory this is possible - stupid but possible - in the old days the getter would be found so this shows that this still happens. eg record getters are looked up after pojo getters
| package graphql.schema.somepackage; | ||
|
|
||
| public class RecordLikeTwoClassesDown extends RecordLikeClass { | ||
| } |
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.
Hence derivation works with record like methods
Moved record like to the front of the search pattern
This changes the
PropertyDataFetcherso that support Javarecordlike naming.eg
object.propertyName()method namingWhile the code here is not specific to record classes only - it will work with them and with any class that uses
propertyName()method naming#2994 has been updated
I have decided to change the strategy - we will look for "direct property" methods first and then getters
So given a field
issues- then we will look forissues()first and then if it fails to find that it will look forgetissuesorgetIssues(since it decapitalizes)I think this is better situation on reflection (pun intented)
Originally I wanted to avoid confusion
where if some one previously had declared a record like method (
behavior()) and didn't want it to be used. BUT this is crazy to have such confusion and I don't think anyone would do it on purpose AND graphql-java 20 can introduce new behaviors if on balance its worth it. And I think it's worth it.So this is the new support.
This will also help Kotlin with its special
isXXXnaming (or lack there of)given
we get this generated
So this new code will find directly named methods first and then use the
get/isstyle naming secondaryThis will work for Kotlin and Java records a like