je me retrouve très souvent dans le cas suivant en utilisant les options :
val myOpt: Option[A] = ...
myOpt match {
case Some(a) => Some(anotherThing)
case None => {
logger.info("...")
None
}
}
J'aimerais pouvoir utiliser plus souvent myOpt.map() pour éviter la
verbosité du pattern matching, mais je vois pas comment faire pour, au
sein du map, appeler mon logger dans le cas du none.
Une idée ? Ne pas appeler le logger ne fait pas partie des idées qui
seront retenues ! :-)
> je me retrouve très souvent dans le cas suivant en utilisant les options :
> val myOpt: Option[A] = ...
> myOpt match {
> case Some(a) => Some(anotherThing)
> case None => {
> logger.info("...")
> None
> }
> }
> J'aimerais pouvoir utiliser plus souvent myOpt.map() pour éviter la
> verbosité du pattern matching, mais je vois pas comment faire pour, au
> sein du map, appeler mon logger dans le cas du none.
> Une idée ? Ne pas appeler le logger ne fait pas partie des idées qui
> seront retenues ! :-)
> Le 28 septembre 2012 13:02, Jérémy Bogatirsky <jbogatir...@gmail.com> a
> écrit :
>> Bonjour tout le monde,
>> je me retrouve très souvent dans le cas suivant en utilisant les options :
>> val myOpt: Option[A] = ...
>> myOpt match {
>> case Some(a) => Some(anotherThing)
>> case None => {
>> logger.info("...")
>> None
>> }
>> }
>> J'aimerais pouvoir utiliser plus souvent myOpt.map() pour éviter la
>> verbosité du pattern matching, mais je vois pas comment faire pour, au
>> sein du map, appeler mon logger dans le cas du none.
>> Une idée ? Ne pas appeler le logger ne fait pas partie des idées qui
>> seront retenues ! :-)
> OK, j'avais pas tiqué que dans le getOrElse je pouvais aussi faire
> plusieurs appels...
> Merci pour le tuyau.
> Le 28 septembre 2012 13:04, Samuel Tardieu <s...@rfc1149.net> a écrit :
>> Le 28 septembre 2012 13:02, Jérémy Bogatirsky <jbogatir...@gmail.com> a
>> écrit :
>>> Bonjour tout le monde,
>>> je me retrouve très souvent dans le cas suivant en utilisant les options :
>>> val myOpt: Option[A] = ...
>>> myOpt match {
>>> case Some(a) => Some(anotherThing)
>>> case None => {
>>> logger.info("...")
>>> None
>>> }
>>> }
>>> J'aimerais pouvoir utiliser plus souvent myOpt.map() pour éviter la
>>> verbosité du pattern matching, mais je vois pas comment faire pour, au
>>> sein du map, appeler mon logger dans le cas du none.
>>> Une idée ? Ne pas appeler le logger ne fait pas partie des idées qui
>>> seront retenues ! :-)
J'en pense qu'il y a toujours un moment où tu devras traiter l'absence de
valeur.
Les avantages d'Option sont :
1. de permettre de choisir le moment de ce traitement (au début ou à la
fin)
2. de documenter dans le code la possibilité d'absence de valeur, et
donc d'indiquer à l'utilisateur s'il doit ou non traiter le cas.
- Ça n'empêche pas les mauvais développements, mais ça donne toutes
les billes pour éviter les erreurs.
3. De fonctionner avec les descendants de AnyVal.
> Le 28 septembre 2012 13:07, Jérémy Bogatirsky <jbogatir...@gmail.com> a
> écrit :
> > OK, j'avais pas tiqué que dans le getOrElse je pouvais aussi faire
> > plusieurs appels...
> > Merci pour le tuyau.
> > Le 28 septembre 2012 13:04, Samuel Tardieu <s...@rfc1149.net> a écrit :
> >> Le 28 septembre 2012 13:02, Jérémy Bogatirsky <jbogatir...@gmail.com> a
> >> écrit :
> >>> Bonjour tout le monde,
> >>> je me retrouve très souvent dans le cas suivant en utilisant les
> options :
> >>> val myOpt: Option[A] = ...
> >>> myOpt match {
> >>> case Some(a) => Some(anotherThing)
> >>> case None => {
> >>> logger.info("...")
> >>> None
> >>> }
> >>> }
> >>> J'aimerais pouvoir utiliser plus souvent myOpt.map() pour éviter la
> >>> verbosité du pattern matching, mais je vois pas comment faire pour, au
> >>> sein du map, appeler mon logger dans le cas du none.
> >>> Une idée ? Ne pas appeler le logger ne fait pas partie des idées qui
> >>> seront retenues ! :-)
Le commentaire de Daniel Spiewak est très clair : utiliser Maybe n'est
intéressant que si on l'utilise vraiment, c'est à dire comme une
structure opaque manipulable uniquement à l'aide de combinateur et
composable, bref une monade pour faire pédant. Cela permet d'écrire du
code clair et surtout, du moins en Haskell, je ne suis pas sûr en
scala, polymorphique dans le type de monade utilisée : on peut ainsi
composer deux fonctions de manière abstraite en ignorant dans quel
univers elles s'appliquent, du moment que leurs univers soient
compatibles.
Et effectivement, le pattern matching sur Option n'est pas différent
d'une vérification de null.
