4 ms·
Sealed classes/interfaces and records are proper sum and product types. The stdlib's Option type predates this language update by a long shot, so it doesn't us
by gf000 4mo ago
Sealed classes/interfaces and records are proper sum and product types.
The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java:
```
sealed class Maybe<T> permits Some, None {
record Some<T>(T obj) {}
record None() {}
}
```
(You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)
- ahoka 4mo agoOr just do as Kotlin and embrace null, but in a type aafe way.
- tsimionescu 4mo agoExcept this is completely wrong. First, a record can't extend anything, it's not even valid syntax, so a sealed class can't permit record subclasses. So no, it's not possible to create a Maybe<T> class in Java that can only represent a Some<T> or a None<T> record. You could do it with regular classes, or if it's ok for Maybe<T> to be an interface. Secondly, regardless of the sealing, nothing in any current or near future of Java prevents you from assigning `null` to any class of any kind you might create. So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`. None of this will change with the adoption of value classes either. So no, there is absolutely no way in Java to create a real Optional/Maybe type that would guarantee that a variable is either an object of a given type or None. There is probably some way to do it for your specific project using annotation processors, of course, but that is very different from having built-in support.
- gf000 4mo agoMistyped, it's sealed interface. > So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`. Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?
- tsimionescu 4mo agoThe whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless. This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't help with at all.
- joe_mwangi 4mo agoSince they plan to have null-restricted types, then I don't see any issue.
- Dylan16807 4mo ago> plan to Well wasn't that the argument above, that the stuff they added so far isn't proper at least in part because they didn't fix that problem yet?
- joe_mwangi 4mo ago> yet But up the comment section, someone thinks they won't be there 'in the future'
- Dylan16807 4mo agoThe comment that says it won't be there in the near future? That's seems like a reasonable claim to me. And a promise to eventually fix a busted implementation doesn't undo it being busted for a significant amount of time.