Simple question about nullable objects. is there ...
# getting-started
w
Simple question about nullable objects. is there a simple way to map them to other objects. Something similar to javas
Optional<String>.map(...).orElse(null)
I'm currently writing this
if (source.mpi.dsEndProtocolVersion!= null) Version(source.mpi.dsEndProtocolVersion!!) else null
but that doesn't feel right to me. Nullable String to nullable Version
d
source.mpi.dsEndProtocolVersion?.let { Version(it) }
✔️ 1
w
🤗 I was attempting something like that. Must have had a syntax error.
(stupid side note)
let
makes me think of variable declaration in BASIC
😄 2
j
To add to the "it doesn't feel right", I would argue your initial approach is factually not right 🙂 between the if(field != null) and the actual usage, the field could have been nullified. So assigning it to a local variable is the safe way of doing it and you wouldn't need to add the
!!
Copy code
val dsEndProtocolVersion = source.mpi.dsEndProtocolVersion
if (dsEndProtocolVersion != null) {
    Version(dsEndProtocolVersion)
} else {
    null
}
the
let
lets you do this without needing to assign the local variable, making it better readable and cleaner to use.
w
To be honest its being controlled by 1 thread.
I get the could be nullified thing but I find the warning to be a pain. but doesn't feel right is the truth of the matter.
j
Even if it is one thread, the variable could change itself upon accessing it
especially if it is not backed by a field
the compiler doesn't know what you know 🙂
w
A String won't nullify itself. I do get the point of it. Its the one thing that I really don't like in the compiler warnings though.
j
well look at this:
Copy code
val myString: String? = "a value"
   get() {
        field?.let {
            field = null
            return it
        }
   }
This is perfectly valid kotlin code (as an example of course, I wouldn't see the actual need for it 😄 )
Copy code
if (myString != null) println(myString!!)
This would now crash. So your warning is not a warning, it is an essential error as Kotlin wants your code to be null safe and it has to take into account fields are prone to change.
w
I'm not arguing that its impossible.
I know its possible, its just not possible for the majority of times I see the warning.
Talking about variable on the stack here, belonging to an object only exposed to the local thread.
j
Well once you use the ?.let or other nullability features you will not run into the errors, so I guess it might be also a matter of getting used to a different coding style
but don't blame the compiler for the errors, it simply cannot understand what you know about your code
especially because Kotlin is not Java (where we are used to a field wouldn't change if you simply read it)
w
I haven't blamed anyone. I think you may be taking what I said as an attack. Yeah I perfer scalas approach to nullable.
I've also had to copy paste a sizable amount of what should be java DTO's into the editor. (3000 lines once converted to kotlin) So running into things. A lot of them are nullable cause I don't yet know what the remote will send. Oh and in the origional example the one I posted. I believe its a val anyway. But naturally they've got behaviour issues. I've got to remove / change to vals & data classes a lot of them.
j
I am not taking it as an attack, but I do try to convince you to not get annoyed by the compiler, because essentially it is just doing its job and it has to accommodate Kotlins features, like overriding the getter of fields, so therefore it should not be compared to other platforms ways of handling nullability.
yeah Java code conversion is a bit more tricky than they make it look
w
It works much better than I would have expected though.
j
As easy as one key combination! (but then failing to mention you might have to rewrite it into a more kotlin friendly way)
w
Yeah thats the thing. I could see it was correct in that it was literally the same behaviour
but I didn't want literally the same behaviour. Including naff serialization, and to string methods, and default nulls and 6 constructors.
Still I wouldn't have done it at all if it was by hand. I'd have included the jar file (and by proxy its dependencies etc.) So very happy with the paste code but it needs work.
Not the importer, our code base.