Un bon design fait la chose courante et sûre par défaut, et permet les choses surprenantes, rarement utiles et plus avancées en les demandant explicitement (mais sans les rendre plus difficiles que nécessaire). Il faut que le choix le plus facile soit aussi le plus correct (parce que c'est celui qui sera fait naturellement).
Le fallthrough n'est pas le bon choix par défaut pour les utilisations usuelles de switch. Est-ce que tu peux montrer un bon exemple en Groovy où le fallthrough est utile ? En C, la classe d'exemple principale est le fait de chaîner plusieurs alternatives à la suite, chacune ayant un code vide sauf la dernière; mais on peut faire ça avec les listes de tests en Groovy.
Le fallthrough par défaut est la source de nombreuses erreurs dans les programmes. Il est courant d'oublier un break (beaucoup plus que d'en rajouter sans faire exprès) et cela change le comportement du programme d'une façon difficile voire impossible à repérer statiquement (contrairement par exemple à une typo dans le nom d'une variable ou l'oubli d'un paramètre à une fonction, erreurs plus courantes encore mais généralement faciles à détecter automatiquement).
Go n'a pas de fallthrough par défaut, mais le permet avec un mot-clé explicite fallthrough (documentation). C'est le bon choix pour une construction switch.
Le choix de Groovy est objectivement mauvais; et le fait qu'ils ne soient pas les seuls à se tromper n'est qu'une maigre consolation.
[^] # Re: Groovy
Posté par gasche . En réponse à la dépêche Découvrir Xtend, un langage extension de Java. Évalué à 6.
Un bon design fait la chose courante et sûre par défaut, et permet les choses surprenantes, rarement utiles et plus avancées en les demandant explicitement (mais sans les rendre plus difficiles que nécessaire). Il faut que le choix le plus facile soit aussi le plus correct (parce que c'est celui qui sera fait naturellement).
Le fallthrough n'est pas le bon choix par défaut pour les utilisations usuelles de switch. Est-ce que tu peux montrer un bon exemple en Groovy où le fallthrough est utile ? En C, la classe d'exemple principale est le fait de chaîner plusieurs alternatives à la suite, chacune ayant un code vide sauf la dernière; mais on peut faire ça avec les listes de tests en Groovy.
Le fallthrough par défaut est la source de nombreuses erreurs dans les programmes. Il est courant d'oublier un
break(beaucoup plus que d'en rajouter sans faire exprès) et cela change le comportement du programme d'une façon difficile voire impossible à repérer statiquement (contrairement par exemple à une typo dans le nom d'une variable ou l'oubli d'un paramètre à une fonction, erreurs plus courantes encore mais généralement faciles à détecter automatiquement).Go n'a pas de fallthrough par défaut, mais le permet avec un mot-clé explicite
fallthrough(documentation). C'est le bon choix pour une constructionswitch.Le choix de Groovy est objectivement mauvais; et le fait qu'ils ne soient pas les seuls à se tromper n'est qu'une maigre consolation.