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.

[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é ?

[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 ?

[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());
}

[maa]

Oui entièrement d'accord. Le problème c'est que j'utilise des classes d'un projet VB qui n'est pas développé par moi.
C'est l'enfer, il multiplie les paramètres optionnels et les demande tous par référence.

Du coup pour chaque paramètre optionnel, je dois :
- déclarer un objet 1 du type du paramètre en l'instanciant avec la valeur par défaut qui est donné au niveau de la méthode VB,
- déclarer un objet 2 dont la référence est égale à objet 1 mais casté dans le type que je souhaite,
- utiliser l'objet 1 dans les paramètre de la méthode concernée avec le mot clé ref.
Tout ça pour des paramètres optionnels qui ne servent à rien...

[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

[maa]

Ok, mais par contre c'est dômmage de ne pas avoir de paramètres optionnels en c#. Pourquoi un tel choix ?

[smyley]

Parce que sinon ce serai du VB ?
Personnellement je trouve qu'il vaut mieux être trop strict que pas assez, celà évite des crash difficiles à corriger. Après, c'est ainsi que le langage a été crée ...

[tomlev]

Je pense que c'est parce que ça peut causer des conflits avec des surcharges de méthode.
Pour reproduire le même comportement, tu peux toujours créer une surchage sans le paramètre optionel, et passer la valeur par défaut à la surcharge qui accepte ce paramètre. C'est un peu plus long à écrire mais au moins ça évite les mauvaises surprises. D'ailleurs je soupçonne que c'est ce que fait le compilateur VB en interne...

[maa]

Quel genre de mauvaises surprises ?

[tomlev]

mmm... j'ai pas d'idée en tête là
f'est comme fa et puis f'est tout

[maa]

En effet, je trouve un cas qui peut facilement induire en erreur :

Considérons ces 2 méthodes :

Code :

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

1
2
3
4
5
6
7
8
 
    Sub MySub(ByVal param1 As List(Of String))
        Console.WriteLine(param1(0))
    End Sub
 
    Sub MySub(ByVal param1 As IList, Optional ByVal param2 As Boolean = True)
        Console.WriteLine(param1(1))
    End Sub

Un utilisateur va appeler la méthode en utilisant la 2ème surcharge comme ceci :

Code :

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

1
2
3
4
5
 
        Dim list As New List(Of String)
        list.Add("1 er élément")
        list.Add("2 nd élément")
        MySub(list, True)

Puis, plus tard il se rend compte que le 2ème paramètre est inutile. Il décide de le supprimer et il se rend compte alors que l'affichage dans la console n'est pas le même...

Je suis d'accord, il vaut mieux être plus rigoureux a l'écriture du code et la compilation si ça peut éviter des mauvaises surprise à l'exécution.
Par contre quand on utilise des classe VB depuis du code C#, ça devient vite galère (pour les raisons cité plus haut). On le voit déjà quand on développe un projet VSTO.

[tomlev]

Ben voilà, t'as trouvé l'exemple tout seul
Il y a aussi le cas des méthodes avec un nombre variable de paramètres (params en C#, ParamArray en VB) qui pose problème.

Par contre quand on utilise des classe VB depuis du code C#, ça devient vite galère (pour les raisons cité plus haut)

[MODE=troll]
Voilà pourquoi il ne faut pas utiliser Visual Basic du tout
[/MODE]
Non, sérieusement, ça fait longtemps que je pense que c'est un mauvais langage et que je ne l'utilise plus du tout... mais bon, des fois on n'a pas le choix.

[smyley]

Attention au troll, en parlant ainsi tu risque de te faire attaquer par tous les VBistes du forum
En général, VB parrait comme un langage plus simple à utiliser avec moins de contraintes que le C# et qu'il est donc plus facile d'aprendre. Après, celà n'est en général qu'une questions de gouts ...

[tomlev]

Ben justement, je trouve pas ça tellement plus facile d'apprendre avec un langage qui te laisse faire plein d'erreurs... mais bon, ça doit venir du fait que Basic (tout court) a longtemps été le langage des débutants, alors tout le monde s'imagine que VB.NET est plus facile que C#. Pourtant la principale différence tient à la syntaxe, qui est finalement assez similaire (plus ou moins les mêmes mots-clés et structures de contrôle).

[maa]

Après je trouve que VB est quand même mieux intégrer à Visual Studio. L'intellisens, la correction des erreurs sans avoir à recompiler, le fait de pouvoir définir des namespace par défaut au projet, etc... sont autant de fonctionnalités que l'on aimerait bien avoir en C#.