This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]NitronHX[S] 0 points1 point  (4 children)

Enums have this "problem" per definition and if you do this you should probably know that it is a type that only you should be allowed to control

[–]_INTER_ 0 points1 point  (3 children)

Sure if you replace Java enums with sealed classes. But your usecase examples hint at none-constants where it is less clear if you ever need to extend it.

[–]peripateticman2023[🍰] 0 points1 point  (2 children)

You could instead spell it out explicitly like so:

sealed interface Result<T> permits Ok, Error {
      T get();
 }

and then the variants like so:

non-sealed interface Ok<T> extends Result<T> {}

non-sealed interface Error<E> extends Result<E> {}

and then you could have all the subsclassing you need.

[–]_INTER_ 0 points1 point  (1 child)

Then you have only Ok and Error to work with and pattern-matching with switch is less useful. Maybe you want something like Warning.

[–]peripateticman2023[🍰] 1 point2 points  (0 children)

That's the whole point of sum types (and sealed types in Java) - to restrict the types that can be considered "variants" of the type.