We can achieve this by simply extending the Java Optional class as follows: fun Optional.toNullable(): T? = this. Ideally this should be available on any Java Optional object (in our project only). So all I need is a simple piece of code that converts a Java Optional into a Kotlin Nullable. They enable us to add functionality to classes that we cannot change or subclass, for example as it is final.
I already knew the concept of extensions from Swift and found that Kotlin also supports extensions. Since we are implementing in Kotlin we would like to use Kotlin Nullables instead and as it turned out we can achieve this very easily. Using this API out of the box would force us to deal with cumbersome Java Optionals. This library is written in Java, hence method signatures look like this: Optional findById(ID var1) We are using a CrudRepository that provides basic functionalities like save(), delete(), findById() etc. This includes Spring Boot Jpa Repositories. I still feel that Option is a better choice for a language in general (I like how it is used in rust std lib), but I should admit that for a language that already has nullable, syntax for it and a lot of utility functions, adding option probably does not make sense.We are using Kotlin and Spring Boot in one of our projects. In most of cases syntax is pretty much the same. you want to distinguish cases user not found and user found, but it didn’t enter their age). If ((mayBeA != null) & (mayBeB != null) & (mayBeC != null)) Ī rare case when it’s not true is when you need to have Option> (e.g. In the case of multiple values it’s depends on the additional language features. If (mayBeValue != null) doSmth(mayBeValue) But as I said, I’m just a n00b and would love to get corrected. I can’t imagine a case where having Option leads to a better code. Kotlin goes to great lengths to make it less harmful but I still don’t like usage of null for representing absent optional value. I’d rather say that null is a bad idea by itself. For example, in Scala there are both null and Option but it seems to me that Option is predominant and null is used mostly for interoperation with Java. You can’t just assign null to them, as we tried above.
All of the types that we’ve used so far in this series - such as String, Int, and Boolean - require you to assign an actual value. Moreover, sometimes you have to deal with nullable Option. Nullable and Non-Nullable Types In Kotlin, we use different types to indicate whether a variable can or cannot be set to null.
It leads to split where some libraries use Option and some use null. I’m a n00b in kotlin, but I’d say that Option is a bad idea for an language having also null.
0 kommentar(er)
