search

Hexworks / mixite

A GUI agnostic hexagonal grid library. Supports a multitude of grid layouts including hexagonal, triangular, rectangular and more.
Apache License 2.0
191 stars 31 forks source link

Use java.lang.Optional on JVM #51

Open drekbour opened 4 years ago

drekbour commented 4 years ago

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

adam-arold commented 4 years ago

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 commented 4 years ago

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

adam-arold commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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