| |
| ▲ | gf000 7 hours ago | parent | next [-] | | 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) | | |
| ▲ | tsimionescu 3 hours ago | parent | next [-] | | Except 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. | | |
| ▲ | munksbeer 34 minutes ago | parent | next [-] | | It's probably a typo. He meant sealed interface. I think that should be quite obvious. | |
| ▲ | gf000 2 hours ago | parent | prev [-] | | Mistyped, 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 2 hours ago | parent [-] | | The 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. | | |
|
| |
| ▲ | ahoka 6 hours ago | parent | prev [-] | | Or just do as Kotlin and embrace null, but in a type aafe way. | | |
| ▲ | gf000 6 hours ago | parent [-] | | "Funnily", having nullable types be practically `T | Null` gives you union types, not sum types (the latter is, importantly are a disjunct union!) The main difference is that (T | Null) | Null = T | Null, while Maybe<Maybe<T>> is different from Maybe<T> | | |
|
| |
| ▲ | an hour ago | parent | prev | next [-] | | [deleted] | |
| ▲ | _kidlike 8 hours ago | parent | prev [-] | | optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records. |
|
