Simple question about nullable objects. is there a simple way to map them to other objects. Somethi...

# getting-started

[Wesley Acheson]

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

[diesieben07]

source.mpi.dsEndProtocolVersion?.let { Version(it) }

[Wesley Acheson]

🤗 I was attempting something like that. Must have had a syntax error.

[Wesley Acheson]

(stupid side note) let makes me think of variable declaration in BASIC

[Joost Klitsie]

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 !!

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.

[Wesley Acheson]

To be honest its being controlled by 1 thread.

[Wesley Acheson]

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.

[Joost Klitsie]

Even if it is one thread, the variable could change itself upon accessing it

[Joost Klitsie]

especially if it is not backed by a field

[Joost Klitsie]

the compiler doesn't know what you know 🙂

[Wesley Acheson]

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.

[Joost Klitsie]

well look at this:

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 😄 )

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.

[Wesley Acheson]

I'm not arguing that its impossible.

[Wesley Acheson]

I know its possible, its just not possible for the majority of times I see the warning.

[Wesley Acheson]

Talking about variable on the stack here, belonging to an object only exposed to the local thread.

[Joost Klitsie]

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

[Joost Klitsie]

but don't blame the compiler for the errors, it simply cannot understand what you know about your code

[Joost Klitsie]

especially because Kotlin is not Java (where we are used to a field wouldn't change if you simply read it)

[Wesley Acheson]

I haven't blamed anyone. I think you may be taking what I said as an attack. Yeah I perfer scalas approach to nullable.

[Wesley Acheson]

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.

[Joost Klitsie]

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.

[Joost Klitsie]

yeah Java code conversion is a bit more tricky than they make it look

[Wesley Acheson]

It works much better than I would have expected though.

[Joost Klitsie]

As easy as one key combination! (but then failing to mention you might have to rewrite it into a more kotlin friendly way)

[Wesley Acheson]

Yeah thats the thing. I could see it was correct in that it was literally the same behaviour

[Wesley Acheson]

but I didn't want literally the same behaviour. Including naff serialization, and to string methods, and default nulls and 6 constructors.

[Wesley Acheson]

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.

[Wesley Acheson]

Not the importer, our code base.