https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
d

dambakk

08/25/2020, 6:29 AM
To answer myself ☝️ , the issue is not sealed classes I believe but rather that
kotlinNothing
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.
p

Petter Måhlén

08/25/2020, 6:53 AM
do you mean
data 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,
Copy code
val missing: OptionalProperty<String>? = null
val presentNull: OptionalProperty<String>? = OptionalProperty(null)
val present: OptionalProperty<String>? = OptionalProperty("foo")
d

dambakk

08/25/2020, 7:10 AM
I think you got it! 🙂 either
T
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)
p

Petter Måhlén

08/25/2020, 7:15 AM
i think i prefer ‘potato’/`T?` 🙂 in the sense that the
OptionalProperty
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.
🙂 1
4 Views