Given the following piece of Kotlin code:
val integer: Int = 42
val nullableInteger: Int? = null
When it is compiled the property types get mapped from the Kotlin type to the correct JVM type:
int integer = 42;
Integer nullableInteger = null;
Well, my question is whether it is possible (now or in the future) to use this mechanism with different types or not.
For example, let’s use it with the JavaFX’s properties.
Currently, to differentiate between an integer property that is nullable from another that isn’t, we have to write it like this:
val property = SimpleIntegerProperty()
val nullableProperty = SimpleObjectProperty<Int>()
println(property.get()) // Initial value `0`
println(nullableProperty.get()) // Initial value `null`
property.set(42)
nullableProperty.set(42)
property.set(null) // Compilation error
nullableProperty.set(null) // Compiles ok
But using the aforementioned mechanism we could simply map the JVM types to more specific Kotlin types:
-
SimpleIntegerProperty<=>SimpleProperty<Int> -
SimpleObjectProperty<Integer><=>SimpleProperty<Int?>
That way the previous code would now look like:
val property = SimpleProperty<Int>()
val nullableProperty = SimpleProperty<Int?>()
This would also help with the nullability problems of SimpleObjectProperty<T> itself, because currently SimpleObjectProperty<String> is virtually the same as SimpleObjectProperty<String?> in the way that you can pass a null to any of them. This problem is similar to the problem with the nullability of the Java collections framework, that Kotlin solves by creating its own List<T>, Set<T>, etc interfaces.