dambakk
08/25/2020, 6:29 AMkotlinNothing
is not a sub-type of NSString
. 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 data class OptionalProperty<T>(val value: T)
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.Petter Måhlén
08/25/2020, 6:53 AMdata class OptionalProperty<T>(val value: T?)
? 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,
val missing: OptionalProperty<String>? = null
val presentNull: OptionalProperty<String>? = OptionalProperty(null)
val present: OptionalProperty<String>? = OptionalProperty("foo")
dambakk
08/25/2020, 7:10 AMT
may be nullable or you can use it like val presentNull: OptionalProperty<String?>? = OptionalProperty(null)
. Potato, tomato 🙂 Is anything else unclear? Also, a custom serializer is still needed as explained in the linked article (somewhat changed tho)Petter Måhlén
08/25/2020, 7:15 AMOptionalProperty
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 (T??
), but that doesn’t seem to work in Kotlin. Also, not quite sure that I remember right.