Certaines bibliothèques open source like twitters semblent avoir une convention pour marquer les classes de cas final
.Quels sont les avantages pratiques du marquage des classes de cas en tant que final dans scala
Mon équipe décide de l'adoption de cette convention, mais nous ne comprenons pas encore les avantages de cela. Actuellement, le seul avantage possible que je peux percevoir est qu'il arrête l'héritage accidentel des classes de cas.
Mais y a-t-il d'autres avantages? Est-ce que cela améliore les temps de compilation ou permet au compilateur d'ajouter des optimisations internes? J'espérais que cela aiderait à détecter les valeurs manquantes dans les correspondances de modèles, mais cela ne semble pas non plus le cas. Dans un script simple comme celui-ci, le compilateur génère un avertissement pour matchSealed
mais pas pour matchFinal
:
sealed case class Sealed(one: Option[Int], two: Option[Int])
def matchSealed(s: Sealed): Unit = s match {
case Sealed(Some(i), None) => println(i)
}
final case class Final(one: Option[Int], two: Option[Int])
def matchFinal(f: Final): Unit = f match {
case Final(Some(i), None) => println(i)
}
Mon impression de final
est qu'il est une restriction plus forte que sealed
, il est donc étrange que cela ne génère pas d'avertissement .
[Cet article] (http://underscore.io/blog/posts/2015/06/02/everything-about-sealed.html) parle de ce problème dans ses commentaires de clôture. L'auteur utilise 'final' en disant que c'est plus descriptif, c'est une convention et cela ouvre des possibilités pour les optimisations du compilateur (bien qu'on n'en connaisse aucune). – rmin