https://kotlinlang.org logo
Channels
Powered by
#getting-started
Title
# getting-started
w

Wesley Acheson

06/19/2020, 11:36 AM
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

diesieben07

06/19/2020, 11:38 AM
source.mpi.dsEndProtocolVersion?.let { Version(it) }
✔️ 1
w

Wesley Acheson

06/19/2020, 11:39 AM
🤗 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

Joost Klitsie

06/19/2020, 2:53 PM
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

Wesley Acheson

06/19/2020, 2:58 PM
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

Joost Klitsie

06/19/2020, 2:59 PM
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

Wesley Acheson

06/19/2020, 3:00 PM
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

Joost Klitsie

06/19/2020, 3:04 PM
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

Wesley Acheson

06/19/2020, 3:05 PM
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

Joost Klitsie

06/19/2020, 3:08 PM
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

Wesley Acheson

06/19/2020, 3:10 PM
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

Joost Klitsie

06/19/2020, 3:13 PM
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

Wesley Acheson

06/19/2020, 3:14 PM
It works much better than I would have expected though.
j

Joost Klitsie

06/19/2020, 3:15 PM
As easy as one key combination! (but then failing to mention you might have to rewrite it into a more kotlin friendly way)
w

Wesley Acheson

06/19/2020, 3:15 PM
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.
Powered by