Discussion :

[maa]

Pourquoi ne peut-on pas tirer partis du polymorphisme dans le cas des méthodes avec des paramètres par référence.
Par exemple le code ne compile pas :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
        static void Main(string[] args)
        {
            string aa = "fdklsm";
            AMethod(ref aa);
        }
 
        public static void AMethod(ref object obj)
        {
        }

Pourtant l'équivalent en VB.net est possible. Pourquoi sur ce point c# est moins fort que VB ?

Merci d'avance pour vos éclaircissements.

mathmax

[smyley]

Et pourquoi pas ça ?

Code :

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

1
2
3
4
5
6
7
8
9
10
 
static void Main(string[] args)
        {
            object aa = "fdklsm";
            AMethod(ref aa);
        }
 
        public static void AMethod(ref object obj)
        {
        }

[SaumonAgile]

Qu'appelles tu polymorphisme ? Dans ton exemple, je n'en vois pas.

[TSalm]

Qu'appelles tu polymorphisme ? Dans ton exemple, je n'en vois pas.

Voilà ici

En informatique, le polymorphisme est l'idée d'autoriser le même code à être utilisé avec différents types, ce qui permet des implémentations plus abstraites et générales.

Mais moi aussi, je pensais que le polymorphisme, c'est des méthodes avec le même nom mais une signature différente, pour appliquer un traitement selon le type en paramétre...


maa: Je ne connais pas le VB, une fonction ne peut être nommé qu'en une fois en VB ?

[maa]

parce que si je veux utiliser aa en tant que string par la suite, je suis obligé de faire un cast.

Pourquoi est-ce que c# impose d'avoir exactement le type du paramètre par référence de la méthode appelée et non un type hérité ?

[SaumonAgile]

parce que si je veux utiliser aa en tant que string par la suite, je suis obligé de faire un cast.

Pourquoi est-ce que c# impose d'avoir exactement le type du paramètre par référence de la méthode appelée et non un type hérité ?

Je suis tenté de te répondre "parce que c'est comme ça", mais je pense qu'il s'agit tout bêtement d'une limitation/contrainte du langage, après que ce soit une contrainte technique, un oubli, ou de la paresse de la part des concepteurs, le résultat est le même.

Après tout, si C# était un langage parfait, on ne s'embêterait plus à parler français

[maa]

Non je refuse de croire que c# est moins bien que VB

[The_badger_man]

Pourquoi s'embéter avec "object" ? Les generics sont là pour ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
static void Main(string[] args)
{
    string aa = "fdklsm";
    AMethod(ref aa);
}
 
public static void AMethod<T>(ref T obj)
{
    Console.WriteLine(obj.ToString());
}

[tomlev]

Non je refuse de croire que c# est moins bien que VB

Et tu as bien raison
D'ailleurs ce n'est pas une faiblesse de C# mais de Visual Basic . Je m'explique...

En fait Visual Basic te laisse faire ça parce qu'il est très permissif au niveau des conversions implicites de type... mais ce n'est pas parce que ça compile que tu ne peux pas avoir d'erreur à l'exécution ! La preuve en image... enfin, en code

Code VB :

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

1
2
3
4
5
6
7
8
9
10
 
    Sub Main()
        Dim i As Integer
        MyMethod(i)
        Console.WriteLine(i)
    End Sub
 
    Sub MyMethod(ByRef x As Object)
        x = Guid.NewGuid
    End Sub

Ce code compile, mais plante... alors que si tu mets "Option Strict On", comme par hasard, ça ne compile plus, on a l'erreur suivante :

Option Strict On disallows narrowing from type 'Object' to type 'Integer' in copying the value of 'ByRef' parameter 'x' back to the matching argument.

En fait, si tu déclares une variable de type T, et que tu la passes à une méthode qui prend un Object par référence, il est possible (et même probable) que la méthode assigne une valeur à ta variable. Et rien ne garantit que ce sera une valeur de type T ! Tu sais juste que ce sera une classe dérivée de Object, mais pas forcément convertible en T... dans l'exemple ci-dessus un Guid n'est pas convertible en Integer.

Donc en fait c'est parfaitement logique que C# ne t'autorise pas à faire ça, et c'est encore une preuve que l'Option Strict devrait être activée par défaut en VB