dambakk08/25/2020, 6:29 AM
is not a sub-type of
. However, the situation above is an implementation of how this article suggests dealing with serializing nullable and optional properties which I think is overengineered. Instead of using the sealed class to represent the three states present-with-value, present-with-null-value, and not-present you can instead have a
and use it as a nullable property type and still cover all the states. It works as before, but is now much more pleasant to use from swift. But please correct me if I’m wrong.
data class OptionalProperty<T>(val value: T)
Petter Måhlén08/25/2020, 6:53 AM
? otherwise, I’m struggling a bit with understanding 🙂 but I think you’re right that you can distinguish the cases with that solution. As in,
data class OptionalProperty<T>(val value: T?)
val missing: OptionalProperty<String>? = null val presentNull: OptionalProperty<String>? = OptionalProperty(null) val present: OptionalProperty<String>? = OptionalProperty("foo")
dambakk08/25/2020, 7:10 AM
may be nullable or you can use it like
. Potato, tomato 🙂 Is anything else unclear? Also, a custom serializer is still needed as explained in the linked article (somewhat changed tho)
val presentNull: OptionalProperty<String?>? = OptionalProperty(null)
Petter Måhlén08/25/2020, 7:15 AM
wrapper doesn’t seem meaningful unless the wrapped property can be null. Also, I think I prefer this version to the sealed classes one. I have a feeling that I saw somewhere some Swift code that used double-optionality (
), but that doesn’t seem to work in Kotlin. Also, not quite sure that I remember right.