Will kotlin ever get proper generics (not the cast...
# compiler
u
Will kotlin ever get proper generics (not the castrated jvm half-assed solution)?
y
I think you can do a lot of it already with
inline
+
reified
u
reifeid doesn't do anything for class level generic parameters I still need a
abtract fun fooType() : Class<T>
to override in sublasses, don't I?
u
I'm sure there were reasons, but state of the matter is that it's lacking compared say to Swift
so I'm wondering if it's even possible to get rid of the java baggage
e
Erasure is probably going to be there for a long time, if not always, as long as interop with Java is a thing.
a
What are you trying to do, anyway? Do you have a longer snippet?
u
basically this
Copy code
class Screen<T> {
	fun createViewModel() {
		val scopes = Scopes.get(T::class) <----
		..
	}
}
e
It's not the best but the typical pattern is
Copy code
inline fun <reified T> Screen() = Screen(T::class.java)

class Screen<T>(private val clazz: Class<T>) ...
u
I should have given more context this is android, I cannot have ctor parameters .. well I can but then they need to be serialized etc
e
Class is serializable so if the class is Serializable it should be fine. I believe Parcels can hold Serializable, so you should be fine if the class is Parcelable
u
not sure if it's worth the reflection runtime penalty 😕
is there no way to trick it like this?
Copy code
class Screen<T> {
    fun foo() {
        
    }

    inline reified <T> whatever() -> KClass<T> {
        T::class
    }
}
e
I think that would be a different
T
, but if you want to specify
T
when you invoke
whatever
that would work (but would be brittle) You might also have to do an unsafe cast
not sure if it's worth the reflection runtime penalty
You mean
Class.forName
(if that's what deserialization is using)? Unless this is a critical section you're probably fine. Not even sure how big of a penalty it is.
j
@AdamW that was a really interesting reading, thanks for sharing!
🤝 1