Just wondering, any reason for not using value (or...

# graphql-kotlin

[dave08]

Just wondering, any reason for not using value (or previously named inline) classes for ID? It could avoid a bunch of needless allocations...

[Dariusz Kuc]

hi 👋 you mean for exposing ID from a GraphQL Kotlin server? I am unsure whether reflections would work with inline classes

[dave08]

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...

[dave08]

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.

[Dariusz Kuc]

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)

[Dariusz Kuc]

disclaimer: reflections might work with inline classes -> don't know as I haven't tried it

[Dariusz Kuc]

we did not have a large use case for ID s so those issues didn't pop up for us (yet)

[Dariusz Kuc]

if you got some ideas how this could work well -> contributions are always welcome 😉