polymorphisme et paramètre par référence.

Depuis la création du basic, la déclaration et le typage des variables ne sont pas obligatoires. (comme en php, je crois)

Ce n'est qu'à partir de VB4 que 'Option explicit' est apparue qui lorsqu'il est à ON oblige les développeurs à déclarer les variables.

Option Strict n'est apparue qu'avec Vb.net (je crois).

Ces options ont toujours été optionnelles pour permettre une compatibilité avec les versions précédentes.
Tu peux convertir du code VB6 en Vb.Net (enfin ça dépend des fois) sans avoir à faire des énormes modifications en ce qui concerne les affectations de variables (voire les déclarations de variables)...

Citation:

---

Envoyé par maa

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

Considérons ces 2 méthodes :

Code:

---

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:

---

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... :roll:

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.

---

Pour revenir un peu sur le sujet, je voulais réagir sur ce message.
Le paramètre optionnel n'est pas vraiment le problème, c'est plus un problème lié au généric.
Tu peux rencontrer le même problème en C#

Ici en executant ma procédure MonExemple le message Test apparait bien.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

private void MonExemple { List<string> test = new List<string>(); test.Add("Donnee1"); test.Add("Donnee2");   MySub(test);   } void MySub(System.Collections.IList param1) { MessageBox.Show("Test");     }

---

Ensuite si je décide d'ajouter une surcharge comme par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

private void MonExemple { List<string> test = new List<string>(); test.Add("Donnee1"); test.Add("Donnee2");   MySub(test);   } void MySub(System.Collections.IList param1) { MessageBox.Show("Test");     } // j'ajoute ici une surcharge void MySub (List<string> param1) { MessageBox.Show("Test2");   }

---

Cette fois, par contre, lorsque je vais executer ma procédure MonExemple, c'est le message "Test2" qui va s'afficher.
Ce problème n'est pas detecté par le compilateur (du moins chez moi)

Citation:

---

Envoyé par Kelpan

Ce problème n'est pas detecté par le compilateur (du moins chez moi)

---

Je ne vois pas en quoi c'est un problème. C'est logique que ce soit la 2eme méthode qui soit utilisée. C'est elle dont le paramètre correspond le mieux.
Il n'y a pas de pb d'ambiguité pour le compilo.

Bonjour.

Citation:

---

Envoyé par 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...

---

T'as encore fait ton Csharpiste trolleur sans faire exprés ! merci pour eux :lol::lol::lol: !

Citation:

---

Envoyé par tomlev

En fait, je pense que VB.NET est plus ou moins équivalent à C#, à condition d'utiliser Option Strict On. Sinon c'est limite dangereux, il donne même pas un warning pour des trucs qui devraient être complètement interdits !

---

Entiérement d'accord, ça devrait être mis en gros quelque part sur le forum VB.Net d'ailleurs avec "Option Explicit On", ça limiterait les posts du à ça :lol: !

Pour revenir aussi au sujet :

Un Object en paramétre ça équivaut à aller directement à l'abattoir...
Au début, on sait ce qu'on doit passer et puis à la fin, les dev se succédant, on ne sait plus... et on se retrouve à passer 1 kilo de pattes dans une procédure éplucher(truc as objet) qui gére les carottes et les concombres.

Pour faire du polymorphisme facilement, il existe les implémentations, et dans ce cas, un seul cast suffit.

Pour les paramétres optionnel, je vois vraiment pas l'intérêt quand on peut utiliser des signatures de méthodes différentes.

Le probléme général de l'utilisation du VB.Net, c'est que comme dit Tomlev (à sa façon :lol:), c'est que celui qui a pris l'habitude du VB ou même du VBA est tenté d'aller vers le VB.Net comme ça, les mains dans les poches ... sans aucune notion de POO de base.

Cdt.

Citation:

---

Envoyé par olsimare

T'as encore fait ton Csharpiste trolleur sans faire exprés ! merci pour eux :lol::lol::lol: !

---

M***e , je suis grillé :mouarf:

Citation:

---

Envoyé par The_badger_man

Je ne vois pas en quoi c'est un problème. C'est logique que ce soit la 2eme méthode qui soit utilisée. C'est elle dont le paramètre correspond le mieux.
Il n'y a pas de pb d'ambiguité pour le compilo.

---

Oui, je suis entièrement d'accord, c'est tout à fait logique que ce soit la 2ème methode qui soit utilisée.
... tout comme l'exemple de maa lorsqu'il supprime le paramètre optionnel...

En fait, le compilateur n'a rien à voir la dedans....