Discussion :

[Arsene Newman]

C# s'enrichit d'un safe navigator operator
A l'image de Groovy, l'opérateur «?.» fait son entrée

C#, l'un des nombreux apports de Microsoft au développement informatique, figure actuellement parmi les langages les plus populaires selon l'index TIOBE, nul doute que son succès est dû au succès conjoint des systèmes d'exploitation Microsoft et de la plate-forme .Net, toutefois il demeure possible que son succès soit relatif à son équipe de développement qui reste à l'écoute de sa communauté et met à sa disposition un système de retour d'expérience (FeedBack) tel que www.uservoice.com.

C'est ainsi donc qu'il a été décidé d'introduire le nouvel opérateur «?.» au langage C#, après que cette suggestion ait perçu plus de 4.313 votes favorables. Appelé aussi en anglais Safe Navigation Operator, l'opérateur «?.» permet de vérifier si la référence à un membre d'une classe est égale à Null au lieu de générer une exception de type NullReferenceException, économisant par la même occasion plusieurs lignes de code au programmeur.

La force de l'opérateur prend tout son sens, lorsqu'il s'agit d'une référence à un membre d'une classe, qui est membre d'une autre classe et ainsi de suite, dans ce genre de situation il s’avère plus difficile de détecter l'origine de l'exception, un exemple vaut mieux qu'un long discours, considérant ce qui suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var g1 = parent.child.child.child;

Si un des child contient la valeur Null, une exception sera levée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var g1 = [parent].[child].[null].child;

L'utilisation du nouvel opérateur permet d'assigner la valeur Null à la variable, dans le cas où une des références vaut Null :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var g1 = parent?.child?.child?.child;
if (g1 != null) // TODO

Au lieu d'un long code équivalent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var item = this.Parent;
item = (item == null) ? null : item.child;
item = (item == null) ? null : item.child;
var g1 = (parent == null) ? null : item.child;
if (g1 != null) // TODO

Enfin Mads Torgersen, le manager du projet C# a révélé que même si cet opérateur a reçu les faveurs de la communauté, son introduction était sur les rails depuis plusieurs mois, vu son utilité, sa facilité d'utilisation. Reste à savoir donc la date de sortie de la prochaine version du langage incluant cet opérateur.

Source : Annonce sur MSDN

Et vous ?
Qu’en pensez-vous ?
Pensez-vous que cet opérateur sera introduit prochainement dans d'autres langages ?

[Derf59]

Pour moi c'est une abérration, je m'explique :

Si l'on écrit
var g1 = parent?.child1?.child2?.child3;

et qu'on imagine fonctionnellement que la valeur [null] est une valeur possible de child3 mais une valeur qui ne devrait pas arriver sur les parent/child1/child2,
ce type d'affectation masque complétement le problème.

var g1 = parent?.child1?.child2?.child3;
if (g1 != null)
...

[Beowulf59]

@Derf59 :

Dans ce cas là l'opérateur n'a pas de raison d'être, vu qu'on ne fait pas child3.child...
Mais si en revanche la valeur null est possible en child2 est pas en child1, rien n'empêche de l'écrire sous la forme :
var g1 = parent.child1.child2?.child3;

Non ? A moins que j'ai mal compris ce point là.

De mon point de vue c'est un opérateur très pratique, mais qu'il faudra utiliser avec parcimonie.

[tomlev]

et qu'on imagine fonctionnellement que la valeur [null] est une valeur possible de child3 mais une valeur qui ne devrait pas arriver sur les parent/child1/child2,
ce type d'affectation masque complétement le problème.

Je ne vois pas où est le problème. Si tu as besoin de savoir si c'est child3 en particulier qui est null, tu peux toujours le tester explicitement, mais il y a énormément de cas où on s'en fout, et où on veut juste la valeur de parent.child1.child2.child3 si elle est disponible, ou null à défaut.

Évidemment ça ne couvre pas la totalité des cas d'utilisation, mais il y a plein de scénarios où ça va rendre le code plus concis et plus lisible. Perso je suis complètement en faveur de cette fonctionnalité.

[DelphiManiac]

Je trouve l'idée très intéressante.

Par contre je ne comprend pas cette remarque

De mon point de vue c'est un opérateur très pratique, mais qu'il faudra utiliser avec parcimonie.

Soit l'opérateur est adapté au besoin et je ne vois pas pourquoi on ne l'utiliserais pas, soit il n'est pas adapté et la question de son utilisation ne se pose pas. Je ne comprend pas en quoi il faudrait être "parcimonieux".

[Derf59]

Je ne vois pas où est le problème. Si tu as besoin de savoir si c'est child3 en particulier qui est null, tu peux toujours le tester explicitement, mais il y a énormément de cas où on s'en fout, et où on veut juste la valeur de parent.child1.child2.child3 si elle est disponible, ou null à défaut.

Évidemment ça ne couvre pas la totalité des cas d'utilisation, mais il y a plein de scénarios où ça va rendre le code plus concis et plus lisible. Perso je suis complètement en faveur de cette fonctionnalité.

Je pense que vous n'avez pas compris ce que je voulais signaler.

Si on écrit
var g1 = parent?.child1?.child2?.child3;
if (g1 != null)

et qu'on obtient une valeur null dans g1, on ne sait pas dire d'où elle provient (parent ? child1 ? child2 ? child3 ?) et que si on considère que dans les spécifications fonctionnelles ni parent/child1/child2 ne devraient retourner une valeur "null", on est là face à un "problème qui est complétement masqué".

[pokap]

C'est un opérateur intéressant mais à double tranchant.
Ça évite d'avoir plusieurs tests à écrire par des if, ce qui alourdi la lecture du code, donc ça reste pour des besoins précis, il y aurait peu de cas d'utilisation.

Par contre avec un tel opérateur on serait tenté de l'utiliser partout alors que ça cacherait des erreurs, ou provoquerait des ralentissements.

Pour moi c'est un opérateur pour un développeur averti qui connait très bien le language et les enjeux du code.

[stailer]

Je trouve ça assez pratique... Même sans partir sur 3 ou 4 niveaux, si déjà je peux faire ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MonObjetNull?.MaPropriété

C'est carrément pratique ! fini les "if" classiques ou "en ligne".
Pour la lecture du code c'est bien plus clair.

A chacun de l'utiliser raisonnablement. Il y a déjà bien d'autres façons de produire du code pourri.

Si les équipes C# ne doivent plus rien proposer au risque que le programmeur ne soit pas raisonnable, plus aucune évolution n'est alors possible sur le langage.

[Beowulf59]

Je trouve l'idée très intéressante.

Par contre je ne comprend pas cette remarque

Soit l'opérateur est adapté au besoin et je ne vois pas pourquoi on ne l'utiliserais pas, soit il n'est pas adapté et la question de son utilisation ne se pose pas. Je ne comprend pas en quoi il faudrait être "parcimonieux".

pokap a résumé ma pensée juste après ton message : je pensais par exemple à certains développeurs débutants qui peuvent être tentés d'utiliser cet opérateur à tout va plutôt que de gérer proprement les erreurs (et je n'avais pas pensé aux problèmes de performances par contre).

[tomlev]

et qu'on obtient une valeur null dans g1, on ne sait pas dire d'où elle provient (parent ? child1 ? child2 ? child3 ?) et que si on considère que dans les spécifications fonctionnelles ni parent/child1/child2 ne devraient retourner une valeur "null", on est là face à un "problème qui est complétement masqué".

Si parent, child1 et child2 ne doivent pas être null, alors il suffit de ne pas utiliser l'opérateur "?." pour y accéder... Le but n'est pas de remplacer l'opérateur ".", seulement de le compléter pour les cas où ça a un sens.

[TiranusKBX]

Comment économiser 2^x lignes de code

[Thorna]

Bonne idée peut-être, mais pas forcément dans le domaine de la réduction du nombre de lignes de tests dans le code : si le résultat est null, selon le programme ça peut être une réponse tout à fait acceptable, mais ça peut être aussi le signe d'une problème quelque part qui va demander ensuite de tester à quel niveau il s'est produit... Et dans ce cas l'écriture classique avec la série de tests sera sans doute préférable. A moins qu'il y ait un (infime) gain de performance à n'écrire qu'une seule ligne avec des ?. dans le cas où la valeur null est rarissime : la série de tests "après coup" ne sera jouée que très rarement.

[...] après que cette suggestion est perçue plus de 4.313 votes favorables. [...]

"On a" perçu quelque chose (auxiliaire avoir), pas "on est", et donc on écrit : que cette suggestion ait perçu (ou ait reçu).
Et l'Académie dit que après "après que", on doit utiliser l'indicatif : "après que cette suggestion a perçu".

[DeVaK]

Je trouve ça très pratique personnellement, et ce parce que je suis confronté à ce problème de if(chose.truc != null) taratata... C'est juste ultra lourd.

Je suis actuellement sur un Intranet Asp.Net avec EF. Dans mon EF j'ai plusieurs clé étrangère qui peuvent être Null pour une personne. Donc souvent dans mon affichage je tente de faire ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

View.nom = Chose.Personne.nom;

Seulement pour accéder à nom, il faut que la propriété de navigation soit pas Null, sinon Exception dont je me fou totalement.

Du coup je serais ravi de pouvoir faire un simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

View.nom = Chose?.Personne.nom;

[miaous]

Ca permet de gagner en lisibilité dans les cas où l'on n'a pas besoin de savoir d’où vient le "null".

[mblaublomme]

L'intéret de cet opérateur est surtout lié à la nature de l'action correctrice qui est exécutée lorsqu'un membre vaut null et que ce n'était pas attendu.

Cet opérateur est très bien si on se contente de faire un "return false" ou un "return" dans un bloc catch de gestionnaire d'exception...

[Pill_S]

Je suis pour! bien utilisé, ça limite le code et simplifie la lecture en supprimant plein de tests.

Je ne vois pas pourquoi ça masquerait l'origine du problème, à nouveau c'est utile quand on ne souhaite que récupérer une valeur parmis une hiérarchie, sans chercher à valider que la dîte hiérarchie est valide en terme business...

C'est quelque chose que j'adorerais voir apparaître en Java, et que j'avais déjà utilisé/implémenté sous forme de requête à la xpath BeanUtils.get(mybean, "prop1.prop2.prop3")

[Derf59]

Si parent, child1 et child2 ne doivent pas être null, alors il suffit de ne pas utiliser l'opérateur "?." pour y accéder... Le but n'est pas de remplacer l'opérateur ".", seulement de le compléter pour les cas où ça a un sens.

On est d'accord que le "but n'est pas de remplacer le ." cependant la dérive de le faire par des personnes qui ne font pas attention à leur code (ou qui ré-utilisent du code par copier/coller) est non négligeable.

C'est un peu comme les exceptions, si il y en a de plusieurs types, c'est pour mieux les gérer si nécessaire, pas juste pour faire (en Java) un
try {} catch (Throwable e) {}

Question subsidiaire :
"si la référence à un membre d'une classe est égale à Null au lieu de générer une exception de type NullReferenceException"
Membre en C# ca se limite à attributs d'une classe ou ca comprend aussi les méthodes de cette classe ?

Ex : Est ce que l'opérateur fonctionne aussi avec des méthodes ?
societe?.getSalarie(1)?.getNom() ou societe?.getSalarie(1)?.nom

[LSMetag]

Je suis globalement favorable à cet opérateur car on est souvent embêté avec des NullReferenceExceptions quand on fait x."..." où x vaut null.
L'avantage, c'est que même si on arrive dans ce cas, le logiciel ne va rien afficher au lieu de planter, ce qui peut être une bonne chose lorsqu'on a un logiciel en production.

Après comme l'ont dit d'autres, à utiliser avec parcimonie. Souvent les nullReferenceExceptions sont des comportements ne devant pas avoir lieu. Le débutant/feignant peut être tenté d'utiliser systématiquement cet opérateur alors que parfois on a besoin d'une erreur signalant un comportement anormal. Donc si utilisation, bien vérifier qu'une éventuelle erreur n'est pas nécessaire.

De plus, cette instruction peut rajouter un test dans des cas où ça ne devrait jamais être null. Il en résulte donc un défaut d'optimisation.

[I_Pnose]

Je suis pour à 100% ! Et pas uniquement parce que je suis confronté à la chose à l’instant même (étant dans un contexte similaire à celui de DeVaK ; un service WCF qui joue avec Entity Framework et qui peut traiter des objets dont les propriétés de navigations sont null).

Il me tarde de voir ça arriver, car les if et autre ternaires imbriqués c’est pas franchement jojo.

[tomlev]

Membre en C# ca se limite à attributs d'une classe ou ca comprend aussi les méthodes de cette classe ?

Les membres d'une classe sont les méthodes, propriétés, évènements, champs et constructeurs

(quoi qu'en l'occurrence cet opérateur n'aurait pas beaucoup de sens pour des évènements ou constructeurs bien sûr...)