Re: ouaa je ne connaissais pas la notation yoda! trop cool

C'est quoi ta solution miracle pour représenter "je suis une fonction qui retourne un Foo si ceci et cela, rien si je peux pas", en gardant Foo comme type de retour, mais en évitant qu'en utilisant ce Foo (bah quoi, le type me dit bien que ça renvoie un Foo, je peux l'utiliser, non ?) ça pète dans les cas où bah... il est pas là ?

Intégrer l’optionalite/présence garantie au cœur du système de typage. Regarde ce que font swift ou kotlin a ce niveau.

T'es sûr d'avoir bien compris le concept d'un système de type plus avancé ?

J’ai très bien compris le concept oui.

guard let bar: Foo? = myFunctionReturningNullSometimes() else { return }
bar.something() // note que sans le guard, tu peux même pas compiler ce code, le compilo te force à gérer la nullité.
// note aussi la concision. Si tu veux pas return, tu peux faire un if let bar.

Face à

Optional<Foo> bar = myFunction()
bar.get().something() // et merde ca peut peter, et le compilo ne me dira rien
// réessayons alors
Foo unwrappedBar = bar.orElse(null); // peut lancer une NPE si je vérifie pas l’implementation de myFunction(), vu que bar lui même peut être null
if (unwrappedBar == null) { return; } // mouais, ben je vois pas vraiment la différence avec juste retourner null, la, tu vois, à part une indirection supplémentaire. Suffit d’un petit refactoring mal placé pour faire disparaître ce if et paf la npe.
unwrappedBar.something()

Les typage moderne refusent de compiler du code qui manipule un pointeur qui peut être null.
Java détourne le système de typage pour te donner un indice que ce que tu manipule peut être null, ne te donne aucune construction pour t’aider à manipuler le null en question, et le wrapper lui même peut être null. Tout ce que ça fait, c’est ajouter une indirection supplémentaire, sans résoudre le problème de base.

Alors tu vas me dire, oui, si ça retourne un optional, par convention, l’optional est garanti non null, sauf qu’au final:

• les garanties par convention, c’est mignon, mais ça protège pas des erreurs humaines
• optional ne peut qu’indiquer l’optionalite, pas la garantie de presence. Ca sonne con comme ca, mais au final tu sais pas si l’absence d’optional indique la présence garantie, ou si l’auteur de la méthode a juste pas voulu utiliser optional.
• le compilo n’a strictement aucun moyen de prouver l’optionalite/présence. C’est très facile de retourner null sur une méthode qui retourne Optional, ou annotée avec @NonNull.
• comme indiqué par ckyl, ça marche pas franchement sur des membres, et c’est super bizarre à manipuler sur des paramètres d’entree d’une méthode.

Au final, tu te retrouves avec une façon de faire qui n’est appliquable que sur une partie du problème, et qui ne résoud même pas vraiment cette partie du problème. En cadeaux bonux, tu te retrouves aussi avec plus de code, et toujours pas de garantie de pas avoir de npe.
Alors, ok, c’est mieux que rien, mais ça reste super bancal.