Ca ressemble a ce qu'on voit dans les languages fonctionnels et qui marche assez bien. Il y a meme une methode map et une flatMap.
Optional en Java n'est pas, et n'a jamais été conçu, d'être l’équivalent d'Option en Scala ou tout autre option type. Son usage est uniquement destiné à indiquer qu'une méthode peut retourner quelque chose ou rien. Utiliser Optional comme paramètre ou membre est un anti-pattern. Ça a été discuté un million de fois lors de son introduction et tu trouveras facilement les arguments en cherchant un peu. Même en type de retour tu verras rapidement les limitations. Combine le résultat de deux fonctions retournant un Optional juste pour rigoler.
En fait, Optional en Java ne résout pas grand chose au prix d'un stress supplémentaire sur le GC en attendant les value types. C'est juste un gros pansement: hey on a complètement merdé notre système de type sur les null et on introduit un gros wrapper pour limiter les dégâts. Si tu résous le problème de gérer correctement la nullité dans les autres cas autre que le type de retour d'une méthode alors Optional devient superflu. Le moins mauvais qu'on puisse faire en Java sont effectivement les annotations de nullité de la JSR 305 / Intellij / Eclipse. Ça passe pour les paramètres et type de retour mais très limités pour les variables et membres d'instance puisque ca manque de concept comme le non null monotone. Celles du https://checkerframework.org/manual/#nullness-checker sont mieux mais il y'a toujours des endroits qui restent merdiques et ingérables mais on arrive à avoir 80% du code sans trop surprise en étant un poil carré. Ca reste assez bancale...
[^] # Re: ouaa je ne connaissais pas la notation yoda! trop cool
Posté par ckyl . En réponse au journal Guido van Rossum se retire de la direction de Python. Évalué à 6.
Optionalen Java n'est pas, et n'a jamais été conçu, d'être l’équivalent d'Optionen Scala ou tout autre option type. Son usage est uniquement destiné à indiquer qu'une méthode peut retourner quelque chose ou rien. UtiliserOptionalcomme paramètre ou membre est un anti-pattern. Ça a été discuté un million de fois lors de son introduction et tu trouveras facilement les arguments en cherchant un peu. Même en type de retour tu verras rapidement les limitations. Combine le résultat de deux fonctions retournant unOptionaljuste pour rigoler.En fait,
Optionalen Java ne résout pas grand chose au prix d'un stress supplémentaire sur le GC en attendant les value types. C'est juste un gros pansement: hey on a complètement merdé notre système de type sur les null et on introduit un gros wrapper pour limiter les dégâts. Si tu résous le problème de gérer correctement la nullité dans les autres cas autre que le type de retour d'une méthode alorsOptionaldevient superflu. Le moins mauvais qu'on puisse faire en Java sont effectivement les annotations de nullité de la JSR 305 / Intellij / Eclipse. Ça passe pour les paramètres et type de retour mais très limités pour les variables et membres d'instance puisque ca manque de concept comme le non null monotone. Celles du https://checkerframework.org/manual/#nullness-checker sont mieux mais il y'a toujours des endroits qui restent merdiques et ingérables mais on arrive à avoir 80% du code sans trop surprise en étant un poil carré. Ca reste assez bancale...