Qu'y a-t-il de si puissant dans flatmap qu'il mérite une telle place dans le folklore Scala?
for
expressions dans la référence du langage. Cela pourrait donner quelques indices.
Qu'y a-t-il de si puissant dans flatmap qu'il mérite une telle place dans le folklore Scala?
for
expressions dans la référence du langage. Cela pourrait donner quelques indices.
Réponses:
Le raisonnement derrière cette phrase est que vous pouvez remplacer beaucoup de code fastidieux if / then / else que vous écririez par des appels à flatMap (et à d'autres fonctions d'ordre supérieur).
Cela est particulièrement vrai pour les options (voir http://tonymorris.github.io/blog/posts/scalaoption-cheat-sheet/ )
Mais cela s'applique également à d'autres monades (même si je dois l'admettre, je ne comprends pas encore exactement les détails moi-même)
Imaginez la situation où vous avez une collection pour laquelle vous souhaitez appliquer une fonction (ou une série de fonctions) où chaque fonction peut renvoyer null. Lorsque vous utilisez réellement null, votre code sera criblé de vérifications nulles. Mais si vous utilisez Options au lieu de valeurs, vous pouvez simplement mapper les valeurs avec les fonctions souhaitées, en chaînant les fonctions dans le cas de plusieurs fonctions et obtenir une collection avec uniquement les résultats qui ne sont pas nuls, ce qui dans de nombreux cas est exactement ce que tu veux.
Puisque cette description est plutôt alambiquée, le conseil plus court "juste une carte plate de cette merde" s'est établi.
L'histoire que j'ai entendue était que deux programmeurs Scala prééminents se jumelaient quand l'un d'eux a commencé à écrire du code comme celui-ci:
option match {
case Some ...
A quel moment l'autre a dit "Qu'est-ce que c'est? Heure amateur? Carte plate cette merde!"
Quant à ce qui est si puissant flatMap
, eh bien ... Premièrement, c'est l'opérateur monadique fondamental. Cela signifie qu'il s'agit d'une opération commune partagée, par exemple, par des conteneurs (tels que des Option
collections, etc.), des continuations, un état, etc. Deuxièmement, même si vous pouvez déconstruire un Option
, qui, par opposition à flatMap
, n'est pas une opération monadique , donc il ne peut pas être aussi largement appliqué. En outre, cela nécessite trop de connaissances sur les données que vous manipulez.
Remarque: précédemment, j'ai dit que la correspondance était plus lente que flatMap
- le contraire est vrai en fait, jusqu'à la version la plus récente de Scala au moment de la rédaction de cet article, 2.10.1.)
val res = for (a <- ma; b <- mb; c <- mc; d <- md) yield f(a,b,c,d)
. Je peux ajouter plus de monades, supprimer des monades et cela reste le même. Notez également qu'il ne se décompose pas en String
, mais en Option[String]
. Bien qu'en fait, il ne se décompose pas du tout. L'une des raisons pour lesquelles certaines personnes n'aiment pas utiliser les conteneurs comme exemples de monades est que vous pouvez sortir des objets des conteneurs, mais toutes les monades ne vous permettent pas de le faire.
L'essentiel flatMap
est qu'il s'agit de la représentation par Scala de l'opération de liaison monadique. Il existe de nombreux tutoriels sur le Web expliquant le but des monades et pourquoi exactement elles sont si utiles; James Iry en a un qui rentre dans les détails.
Option
c'est juste l'un des nombreux flatMap
cas d'utilisation. Bien sûr, si vous voulez observer les monades dans leur «habitat naturel», vous devriez consulter Haskell. La seule différence est que les Haskellers disent: "Juste >> = cette merde!"
Runar Bjarnason est la personne que vous recherchez pour l'origine.
Réaliser pourquoi il est si puissant est quelque chose qui ne peut venir qu'avec le temps pour être honnête. La classe Option est le meilleur point de départ pour voir comment vous mettriez à plat à plusieurs reprises une série de recherches (par exemple) dans un résultat final.