Las sealed classes de Java no protegen a los consumidores de tu API
Java sealed classes and exhaustive pattern matching
Java 17 introdujo las sealed classes para que el compilador verifique exhaustividad en los switch, pero añadir un subtipo rompe a los consumidores que no se recompilan: el error pasa de compilación a una MatchException en tiempo de ejecución. El autor concluye que son útiles dentro de un componente, donde todo se recompila junto, y peligrosas en APIs públicas, y señala ese fallo en la propuesta de objetos criptográficos PEM de OpenJDK.
Añadir un nuevo subtipo a una sealed class puede romper a los consumidores de ese código, a menudo solo detectable en tiempo de ejecución.
- shepherdjerred
Me encanta lo lejos que ha llegado Java. Aun así sigo prefiriendo TypeScript, ya que hago mucho trabajo de frontend y prefiero usar el mismo lenguaje en todo el stack.
Dicho esto, ¡puedes hacer pattern matching exhaustivo en TypeScript! https://github.com/gvergnaud/ts-pattern
- another_twist
Tardé un tiempo en acostumbrarme a sealed y no terminaba de verle la utilidad. Pero parece que a la IA le encanta para Java, así que lo probé y ahora lo entiendo. Es como un mecanismo de control de acceso realmente bueno, sobre todo si usas DI y quieres deprecar algunas cosas. Aparte, por supuesto, del pattern matching, que viene de perlas para mensajes orientados a eventos donde la forma del payload cambia.
- armchairhacker
Java también tiene patrones recursivos y (quizá todavía en preview) patrones literales: `switch (x) { case A(B(true, var c)) -> f(c); }`
- timshel2
Scala lanzando puñetazos al aire ahora mismo
- panny
No creo que necesites esos defaults del switch con los tipos sealed. No lo he comprobado con un compilador, pero creo que son innecesarios.
- Larrikin
Java sigue intentando alcanzar a Kotlin
https://kotlinlang.org/docs/sealed-classes.html
No me importaba Java cuando las comparaciones eran con C++, Ruby y Python. No encuentro ninguna razón para volver después de Scala (que pareció fracasar por ser indiscriminada) y especialmente después de Kotlin