Break and Continue:
Dans une conférence sur Scala , Martin Odersky a donné 3 raisons de ne pas inclure la pause ou de continuer sur la diapositive 22:
- Ils sont un peu impératifs; mieux utiliser de nombreuses fonctions plus petites.
- Indique comment interagir avec les fermetures.
- Ils ne sont pas nécessaires!
Et il dit ensuite: "Nous pouvons les prendre en charge uniquement dans les bibliothèques." Sur la diapositive 23, il donne le code qui implémente break
. Bien que je ne connaisse pas assez bien Scala pour en être certain, il semble que l'extrait court sur cette diapositive soit tout ce qu'il faut pour implémenter break
, et cela continue
pourrait être implémenté dans un code qui est tout aussi court.
Être capable d'implémenter des trucs comme ça dans les bibliothèques simplifie le langage principal.
Dans 'Programming in Scala, Second Edition', de Martin Odersky, Lex Spoon et Bill Venners, l'explication suivante est donnée:
Vous avez peut-être remarqué qu'il n'y a eu aucune mention de break
ou continue
. Scala laisse de côté ces commandes car elles ne correspondent pas bien aux littéraux de fonction ... Il est clair ce que continue
signifie à l'intérieur d'une while
boucle, mais qu'est-ce que cela signifierait à l'intérieur d'un littéral de fonction? ... Il existe de nombreuses façons de programmer sans break
et continue
, et si vous profitez des littéraux de fonction, ces alternatives peuvent souvent être plus courtes que le code d'origine.
Revenir:
Les retours peuvent être considérés comme un peu impératifs dans le style, car return est un verbe, une commande pour faire quelque chose. Mais ils peuvent également être vus d'une manière purement fonctionnelle / déclarative: ils définissent quelle est la valeur de retour de la fonction (même si, dans une fonction à plusieurs retours, ils ne donnent chacun qu'une définition partielle).
Dans le même livre, ils disent ce qui suit à propos de return
:
En l'absence de toute return
déclaration explicite , une méthode Scala renvoie la dernière valeur calculée par la méthode. Le style recommandé pour les méthodes est en fait d'éviter d'avoir des return
instructions explicites et surtout multiples . Considérez plutôt chaque méthode comme une expression qui produit une valeur, qui est renvoyée.
Les méthodes terminent et renvoient une valeur, même si une return
instruction n'est pas utilisée, donc il ne peut y avoir de problème avec les fermetures, car sinon les fermetures ne fonctionneraient pas.
Il ne peut pas non plus y avoir de problème de bon maillage avec les littéraux de fonction, car la fonction doit quand même retourner une valeur.
break
et j'aicontinue
besoin de machines de nettoyage supplémentaires. OTOHreturn
est un moyen de terminer une fonction de manière ordonnée, et toute machine de nettoyage est déjà là de toute façon.