I'm not sure I'm following with the article, I don't think there's much of a problem treating `java.util.Optional` as a `Maybe`-like.
Regardless of "monad" label, it does work ok at modelling a container with [0..1] element and provides `Functor` fmap + `Monad` bind to operate the values.
Looking at `Omittable` APIs, I don't think there's much difference with the latest `java.util.Optional`? Why should I pick `Omittable` over standard library `Optional` then?
Personally, I roll my own "header-only"-style `Nilable<T>` on personal repo. I like to merge `orElse` and `orElseGet` into a single overloaded `orElse`, turning it to bare `null` resistant due to deliberate ambiguous method resolution.
Curiously none of 3rd party `Option`-like JVM libraries have this behavior, so I had to make it myself.
RecursionLab•4mo ago
This is the right cut: make absence first-class instead of overloading `null`. `Optional` can’t express “explicit null,” so PATCH and filter semantics collapse. `Omittable` restores the algebra: `{absent | present(null) | present(value)}` and stays lawful under `flatMap`. Pattern matching + JSpecify reads clean.
Next wins to make this ubiquitous:
1. Jackson module that preserves omission on deserialization.
2. Spring MVC/WebFlux binders for `@RequestParam`/`@RequestBody`.
3. JSON Schema/OpenAPI mapping for `undefined` vs `null`.
4. JPA/SQL bridge to avoid accidental `SET col = NULL`.
5. Property-based tests for the monad laws.
Ship tiny `omittable-jackson` and `omittable-spring` starters and this becomes the default tri-state for Java APIs. Good luck; may every `null` be intentional.
zeendo•4mo ago