Use java.lang.Optional on JVM

[drekbour]

Use expect / actual to allow Java 8 to provide the proper Optional implementation.

• https://stackoverflow.com/questions/59006733/kotlin-multiplatform-support-for-optional/59007511?noredirect=1#comment104264493_59007511
• https://github.com/h0tk3y/mpp-optional-demo

[adam-arold]

We already have Maybe in Cobalt which we could use in Mixite to fix this, but I'm waiting for Arrow to become a MPP project (it is going to happen soon), then we could just use their implementation.

[drekbour]

Yes. It was that Maybe that had me shivering and raising this :)

[adam-arold]

So the Maybe is there because of MPP. We might be able to use Optional on the JVM but there is no such construct for Javascript / Native.

[drekbour]

I see that Optional + Kotlin is a huge talking point in general. Should Mixite even bother? Or perhaps simply supply a JVM-only HexagonalGridDecorator which converts Hex? to Optional<Hex>.

Certainly all the "internal" uses of Maybe should be removed IMO!

[adam-arold]

I'm not sure I follow. The problem in general is that we have to maintain API compatibility with Java, so that's why we have Maybe. It is going to be better when we can switch to Arrow's Option.

[drekbour]

Looks impressive. Arrow appears to be a full-FP attempt (every language has one!) however modular they present it as. Do you feel that introducing the arrowverse is a little heavy for a small lib (like when hexameter enforced rxjava).

I'm not massively troubled but IMO Optional isn't adding much here (hence why KT doesn't have it). Personally I would deprecate those methods and move away rather than reinforcing the position by using a 3rd-party impl.

[adam-arold]

What alternative do we have to Optional? I don't really want to use nullable variables.