-
Notifications
You must be signed in to change notification settings - Fork 2
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
refactor: Reduce coupling with Type #119
Conversation
bfb62a1
to
2406400
Compare
3f8c00e
to
78c6815
Compare
ff596cf
to
c1fbe34
Compare
ca6f6b4
to
36172d7
Compare
6f67c79
to
a039cad
Compare
36172d7
to
92bdfd4
Compare
a039cad
to
3b4af49
Compare
85b354e
to
9625454
Compare
The current implementation is heavily coupled to `Type` which itself is heavily coupled to actual Kotlin classes. This tries to move away from `Type` when it is not needed to simplify working with non-Kotlin schemas (like schemas created from SDL or introspection queries).
9625454
to
b46b0c3
Compare
fun isList(): Boolean = when { | ||
kind == TypeKind.LIST -> true | ||
ofType == null -> false | ||
else -> (ofType as __Type).isList() |
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.
Would (ofType as? __Type)?.isList() ?: false
also work here without the second when case plus it would be a safe cast?
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.
Would work, yes. The current cast should also be safe, though, shouldn't it? I'll have a look in my next PR.
The current implementation is heavily coupled to
Type
which itself is heavily coupled to actual Kotlin classes. This tries to move away fromType
when it is not needed to simplify working with non-Kotlin schemas (like schemas created from SDL or introspection queries).