Discussion :

[I_Pnose]

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

Dans la mesure où en C#, les propriétés abstraient l'implémentation des méthodes SetQuelquechose et GetQuelquechose, j'aurais tendance à dire oui.

ton code java ressemblerait à ça en C# :
societe?.Salarie[1]?.Nom (ou Nom est une propriété, et donc intrinsèquement, un appel de méthode).

[OsoNet]

Pour moi c'est une solution bancal pour un problème mal identifié.

Le vrai problème n'est pas dans une chaine A.B.C.D.E qui peut provoquer une erreur liée à une référence nulle.
Au delà du fait que si une ligne comme la précédente est vraiment nécessaire, faut peut être revoir l'architecture du projet, le vrai problème ce situe dans la gestion des instanciations en .Net qui est complètement insuffisante pour des projets complexes.

Vu comme çà, la solution serait plutôt un opérateur de Cardinalité avec une modification de l'instanciation pour mieux gérer çà (avec des contrat de code par exemple)

Exemple d'opérateurs de cardinalité:
- Dim Nullable? as MonObject: Cardinalité = 0 ou 1 => Nullable
- Dim NotNullable as MonObject: Cardinalité = 1 => Not Nullable (en .Net c'est l'inverse)
- Dim Plusieurs* as MonObject: Cardinalité = 0 à l'infini
- Dim 1Minimum+ as MonObject: Cardinalité = de 1 à l'infini

On remarque tout de suite les contrats de code possible pour que le compilateur puisse géré çà tranquillement.
On remarque aussi que l'instanciation par défaut du .Net ne convient plus.
En bonus, on obtient une définition plus pratique des contrats sur les tableaux et notamment sur leurs dimensions avec les contrats qui vont bien.
Si en plus ces opérateurs sont sur-chargeables, ont peut s'en servir pour créer des fabriques directement en code voir même des patterns de composition pour les regex ou autre idée folle du genre .

Enfin moi je dis çà, je dis rien hein

[DonQuiche]

Pour moi c'est une solution bancal pour un problème mal identifié.

D'un côté je trouve le fond de ton commentaire pertinent, de l'autre je trouve sa formulation beaucoup trop légère.

* A l'époque où Java et C# ont été introduits ils ajoutaient déjà beaucoup d'innovations. Difficile de leur reprocher de ne pas avoir été encore plus loin.

* Le problème est loin d'être trivial (contrairement à l'impression que tu donnes) et je parie qu'un tel système de types n'est pas accompli sans compromis. Notamment je n'ai jamais travaillé avec un langage incluant l'information de nullité dans le système de types mais cela pose tout un tas de problèmes à résoudre, du marshalling jusqu'aux tableaux. J'aimerais en faire l'expérience mais je me demande si c'est vraiment appréciable au quotidien. Car toutes les initialisations par simple mise à zéro doivent être prohibées pour les types non-nullables et donc tout doit être explicite, ce qui peut peut-être devenir fastidieux. Peut-être pas plus que les tests de nullité en série, certes, mais pas forcément moins non plus.

A priori ça m'a toujours semblé être une bonne idée. Mais de là à prendre les choses de haut à base de "y a qu'à"...

[OsoNet]

DonQuiche, je suis entièrement d'accord avec toi, seulement le sujet est vraiment complexe et donc très difficile à résumer dans un simple commentaire.

Loin de moi l'idée de prendre les choses de haut, j'aime bien le .Net, mais j'aime bien aussi garder l'esprit critique.

Le principal problème du .Net n'est pas son état actuel ou les raisons qui ont poussées à ce résultat, mais le manque de liberté et d'ouverture limitant son évolution (les mauvaises fermetures du .Net m'exaspère car elles empêchent les évolutions libres ou expérimentale de la plateforme). Quand on gratte un peu sur le sujet en .Net on se retrouve bloqué par le système de type fermé et non extensible du .Net (comme souvent en .Net, y a toujours un Friend ou Internal en C# qui bloque tout) et ce n'est qu'un exemple parmi tant d'autre.

Tout cela mériterait un article à part entière tout comme le problème et la solution (si il s'agit vraiment d'une solution, ce qui reste à confirmer) soulever ici.

Moi aussi j'aimerais expérimenter mes idées (celle présentée ici n'est qu'une idée parmi tant d'autres) hélas en .Net aucune n'est possible donc j'en suis arriver au point de faire mon propre langage pour les expérimenter et c'est vraiment dommage d'en arriver là pour d'obscure raison...
Je m'arrête là je pourrais en écrire des tonnes sur ce sujet.

Le côté trivial à toutefois du bon puisqu'il permet aux gens de prendre l'idée de cardinalité exprimée dans mon message comme une idée et non comme une solution miracle (du moins je crois).
J'espère en passant que cela t'aura permis à toi et aux autres lecteurs de réfléchir au problème sous un autre angle, c'était le but principal.

Sur ce ++ et bonne continuation.

[DonQuiche]

J'espère en passant que cela t'aura permis à toi et aux autres lecteurs de réfléchir au problème sous un autre angle, c'était le but principal.

Rassure-toi en ce qui me concerne ça fait un bail que j'explore ces problèmes. Tu n'es pas le seul à déplorer le système de types de C# et avoir tenté de le modifier, nous partageons une passion en commun.
Au passage M#, le futur langage système de MS, intègrera la nullité dans son système de types.

[OsoNet]

Comme quoi les grands esprits se rencontrent

Je me suis pris tellement la tête sur les trucs de MS et j'en ai tellement marre de leur baratin, que je ne compte plus sur eux pour trouver la solution aux problèmes qu'ils apportent.

Sauf si ils se reprennent en main, pour moi l'avenir se fera sans eux.

Mais bon c'est mon côté radical, je ne suis pas forcément un exemple à suivre

[blbird]

Quand on gratte un peu sur le sujet en .Net on se retrouve bloqué par le système de type fermé et non extensible du .Net (comme souvent en .Net, y a toujours un Friend ou Internal en C# qui bloque tout) et ce n'est qu'un exemple parmi tant d'autre.

Aaaah merci. Entièrement d'accord. Ce système d'Internal ou tout empêchement d'héritage m'a toujours semblé incroyable, à l'opposé complet des principes de POO et d'ouverture de code.
Quand je l'avais signalé il y a de nombreuses années, venant de passer du Java au DotNet, on m'avait dit que c'était "normal" et "nécessaire".

Bref, entièrement d'accord avec vous sur ce sujet.

Par contre, la notion de surcharge d'opérateurs est pour moi quelque chose que j'éviterais le plus possible dans un langage, où on en arriverait rapidement à ne plus savoir ce qu'un "+" ou un "." font dans un code, sans des recherches approfondies...

[Gluups]

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)
...

Non non, du tout, ce type d'affectation, comme tu dis, a été clairement annoncé comme inadapté à ce cas précis, qui reste à devoir être codé par
if (parent==null){throw new exception("Erreur : parent nul");}
if (child1==null){throw new exception("Erreur : child1 nul");}
if (child2==null){throw new exception("Erreur : child2 nul");}
var g1 = parent.child1.child2.child3;

Mais c'est un parapluie supplémentaire, car ces contrôles devraient être faits dans les constructeurs.

Un nouvel opérateur n'empêche pas de lire les docs : son utilisation est réservée au cas où parent, child1, child2, peuvent être nuls, pour détecter que c'est le cas de l'un d'eux indifféremment.

Du moment qu'on réserve le nouvel opérateur à l'utilisation qui en a été présentée, plutôt qu'à faire des bêtises avec, il faut bien reconnaître qu'il apporte un progrès net en lisibilité du code, par rapport aux cinq lignes citées dans la présentation.