fvasco
August 9, 2019, 1:16pm
6
Hi @mshere96 ,
this could be done, but in such case this class become a part of the public ABI, so the compiler have to generate it even it is not used anymore, so I shall discard this path.
Instead many projections of the same class exposes to performance problems (CPU L1 cache will contains a lot of duplicated code) and may become too expensive for Android application (total method count is limited).
I don’t think that this is a bad idea, however JVM type erasure is a big obstacle.
Currently we are discussing a similar proposal
# Compile time dependency resolution
* **Type**: Design proposal
* **Author**: Raul Raja
* **Contributors**: Tomás Ruiz López, Jorge Castillo, Francesco Vasco, Claire Neveu
* **Status**: New
* **Prototype**: [initial implementation](https://github.com/arrow-kt/kotlin/pull/6)
## Summary
The goal of this proposal is to enable **compile time dependency resolution** through extension syntax. Overall, we want to enable extension contract interfaces to be declared as constraints in function or class constructor arguments and enable the compiler to automatically resolve and inject those instances that must be provided with evidence in one of a given set of scopes. We'll cover these later in the Extension resolution order section. In the case of not having evidence of a required interface (program constraints), the compiler would fail and provide the proper error messages.
This would bring **first-class named extension families** to Kotlin. Extension families allow us to guarantee that a given data type (class, interface, etc.) satisfies behaviors (a group of functions) that are decoupled from the type's inheritance hierarchy.
Unlike the traditional subtype style composition where users are forced to extend and implement classes and interfaces, extension families favor horizontal composition based on compile time resolution between types and their extensions.
## Motivation
* Support compile-time verification of program dependencies (extensions).
* Enable nested extension resolution.
show original
I proposed an enhancement to emulate reified type, see here
Hi,
this proposal follow the typeclass on Kotlin.
The class kotlin.reflect.KClass can become a typeclass, ie:
typeclass KClass<T : Any>
For each exsisting type T the Kotlin compiler is already able to define a specific instance of KClass<T>, currenlty it is expressed as T::class.
The goal is to mimic a reified type without requiring the inlining.
A simple example is:
class TypePredicate<T> : Predicate<T> given KClass<T> {
override fun filter(e : T) = e is T
}
val stringTypePredicate …
3 Likes