One of the common solution to `null`-related probl...

# codingconventions

[karelpeeters]

One of the common solution to null-related problems in Java is to return a "default value", and this works especially well with collections, there's rarely a reason for them to be null. Just make your mehods return empty collections instead.

[prat]

we try to use empty collections where possible. Unfortunately, some parts of the code interface with legacy Java code

[karelpeeters]

Sure, not much you can do about that.

[codeslubber]

Empty collections is better but null is a tad more complicated than that. Unless every endpoint in your domain is wrapped in a collection..

[karelpeeters]

What do you mean with "endpoint in your domain"?

[codeslubber]

I am saying if you have a domain model, it will have nulls in it. For instance, I have a person class, it has an email address. I might not have that attribute the first day the person comes along. I have to put a record in the database. Most people allow nulls of various attributes in a domain model. Trying to remove all nulls is a good and noble goal, also not very realistic. If we got our hands on a smattering of domain models, classes and/or database schemas, we would find a high density of nulls. You cannot make them all vanish by telling people about empty collections.

[karelpeeters]

Yes that's true, I was talking about the case where it's about a collection value being null. To stick with your Person example, let's say it has a list of friends, that should be an empty list from day 1.

[codeslubber]

Sure, and as I said I agree with that.

[raulraja]

I see null as unrelated to absence. null looks like a missing value on a valid reference but for the rest of modeling concerns there are proper datatypes that are mainstream in many other langs beside java/kotlin. Option comes to mind, but despite Kotlin's superior treatment of nullable types over other langs like Scala I still see myself and Kotlin code where null is present everywhere whereas in Scala for example everyone uses Option to model absence and it's rare to see null in code bases at all.

[karelpeeters]

What's the difference between using Optional vs a nullable value in Kotlin? Both force you to handle to "null" case.

[raulraja]

All three Optional, scala.Option and nullable types ? in Kotlin have operators that let you shoot yourself in the foot !! or .get when really the proper treatment should be to consider folding the datatype contemplating the absence with a default value or path. Kotlin's lack of monadic comprehension which is something we address in Kategory does not really let you compute over monadic values such as those of option in a way that does not require nested lambdas or to much boilerplate IMO. Most langs that favor Option style datatypes over null checks have syntax to compute over the assumption that the value is fulfilled and if it is ever empty it shortcircuits yielding None or something equivalent.
Nullable types are definitely an improvement but you can get away ignoring null altogether with a proper Option datatype in the same way we use List to represent multiple values.

[raulraja]

@karelpeeters my guess is using nullable types ? is more efficient from a performance standpoint since it's implemented as part of the Kotlin typesystem rather than an actual datatype subject to instantiation and other things that nullable types probably don't do.

[prat]

imo, Optional is a bit more composable with more APIs e.g. map, flatMap, filter, append, forEach

[karelpeeters]

@raulraja There's no way to prevent people from shooting themselves in the foot, using !! is a compiler warning, right?

[karelpeeters]

@prat Can't you define those as extension functions on Any??

[raulraja]

@karelpeeters yeah, !! is a lot better than Optional.get or Option.get which IMO it should only appear in scene if you do something like import Option.unsafe.* or something along those lines so you understand what you are doing. This also applies to list[0] and all other unsafe method/operators. A lot of bugs could be prevented if these features were opt in.

[prat]

@karelpeeters sure, but it'd be great if those are build-in. anyway, let is actually good enough for me