-
-
Notifications
You must be signed in to change notification settings - Fork 40
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
Make KtorClient private and depend on ApiClient in generated code #207
Comments
If you pass classes as parameters, you could define reified inline extension functions afterwards, like so: import kotlin.reflect.KClass
interface ApiClient {
fun <T: Any> get(clazz: KClass<T>): T
}
inline fun <reified T: Any> ApiClient.get(): T = get(T::class) |
The reified fun's are not in the interface so we won't be able to use the interface in the generated API classes with that approach, besides. Ktor doesn't allow passing the return type as a class, they ONLY support reified types (not sure why they chose to do that..). |
You could import the extension function, or only support the extension functions (aka syntactic sugar) for consumers of the API. Also, if I'm not mistaken, reified actually means simply passing the class to the function as a parameter, hidden behind compiler magic. |
I get your point but the problem is that Ktor doesn't support passing the class as a parameter. It requires a reified type send via generic (https://ktor.io/docs/response.html) but interfaces do not support it. |
I'm thinking we might want to switch from Ktor to something more low-level (like okhttp). This would give us more control and reduce the libraries dependencies. Besides, we don't use most of the Ktor stuff. The biggest change would be to do the JSON serialization ourselves (using kotlinx of course). |
Although we do use the ApiClient interface in most places it doesn't include the request, get, post and delete functions. This is because we use inline functions with reified types, which are not supported when using interfaces. Preferably we'd fix this by passing the class as parameters instead of using generics but when I looked into this it didn't look like a possibility.
Separating the KtorClient (implementation) from the ApiClient (interface) it would allow the usage of custom HTTP clients and make it easier to change it if we decide to drop Ktor at some point.
The text was updated successfully, but these errors were encountered: