https://kotlinlang.org logo
#graphql-kotlin
Title
# graphql-kotlin
d

dave08

03/07/2021, 12:45 PM
Just wondering, any reason for not using value (or previously named inline) classes for ID? It could avoid a bunch of needless allocations...
d

Dariusz Kuc

03/08/2021, 2:37 AM
hi 👋 you mean for exposing
ID
from a GraphQL Kotlin server? I am unsure whether reflections would work with inline classes
👋🏼 1
d

dave08

03/08/2021, 3:17 AM
Yes, I do. It could be you're right about reflection though, I thought you didn't need reflection for that one... I guess this could be another advantage of using an annotation processor for the schema generation 😉. It just occured to me, since I find myself creating tons of IDs... also, why should the ID not be generic? Then you could use toString to convert it, since ids can come from Ints or Longs too...
I mean, by kapt helping, is that there could be an
@ID
annotation, instead of boxing all ids for nothing, so even if reflection doesn't work on inline classes, allocations could be avoided... and ids could also use any type. If ID was being used to provide extra functionality, it would justify the allocations, but it just seems to be a marker.
d

Dariusz Kuc

03/08/2021, 3:33 AM
as per the https://github.com/ExpediaGroup/graphql-kotlin/issues/317 by allowing different types it would complicate the input coercion rules (output as you said is easy)
disclaimer: reflections might work with inline classes -> don't know as I haven't tried it
we did not have a large use case for
ID
s so those issues didn't pop up for us (yet)
if you got some ideas how this could work well -> contributions are always welcome 😉
2 Views