La différence entre VB, VB.NET et C#

Citation:

---

Envoyé par smyley

Combien de personnes, même ici, ont déjà réussit à faire des applications sans même savoir qu'il faut créer des instances d'un objet avant de l'utiliser, et tombent après sur des problèmes existentiels ? :mouarf:

---

C'est clair... c'est une des choses qui me font considérer VB.NET comme un langage dédié aux débutants : surtout, ne pas faire peur au développeur en lui expliquant que sa Form est en fait une instance d'une classe :aie:

Citation:

---

Support for named indexers.

---

kesako ?

et les itérateurs, c'est quoi le principe ?

Citation:

---

Envoyé par Pol63

Citation:

---

Support for named indexers.

---

kesako ?

---

En gros, c'est une propriété qui prend des paramètres. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9

Private m_Scores As Dictionary(Of String, Integer) Public Property Score(ByVal playerName As String) As Integer Get Return m_Scores(playerName) End Get Set(ByVal Value As Integer) m_Scores(playerName) = Value End Set End Property

---

Et tu l'utilises comme ça :

Code:

---

1 2 3

Dim scoreDeJoe As Integer = toto.Score("Joe") ' Ou encore : game.Score("Joe") = 42

---

Bref... au final c'est un peu pareil qu'une méthode, sauf que tu peux aussi affecter une valeur

En C# on peut créer des indexeurs, mais seulement sur le type lui même :

Code:

---

1 2 3 4 5 6 7

private Dictionary<string, int> _scores;   public int this[string playerName] { get { return _scores[playerName]; } set { _scores[playerName] = value; } }

---

Et on l'utilise comme ça :

Code:

---

1 2	int scoreDeJoe = toto["Joe"]; toto["Joe"] = 42;

---

Citation:

---

Envoyé par Pol63

et les itérateurs, c'est quoi le principe ?

---

En gros, c'est une méthode qui renvoie un IEnumerable<T>, sans passer par une collection intermédiaire (donc pas besoin d'avoir fini de générer les résultats pour commencer à les lire). Un exemple bidon :

Code:

---

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

public IEnumerable<int> Fibonacci() { int a = 0; int b = 1;   while(true) { yield return a; int tmp = a + b; a = b; b = tmp; } }

---

Le compilateur transforme ce code en une implémentation de IEnumerator<int>, avec une machine à états.

C'est utilisé un peu partout dans Linq... par exemple, la méthode Where doit être un truc comme ça :

Code:

---

1 2 3 4 5 6 7 8

public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate) { foreach(T item in source) { if (predicate(item)) yield return item; } }

---

La méthode Select :

Code:

---

1 2 3 4 5 6 7

public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector) { foreach(T item in source) { yield return selector(item); } }

---

Un des aspects intéressants de cette technique est que l'exécution du code de l'itérateur ne se fait que quand tu commence à l'énumérer. En gros, si tu fais juste ça :

Code:

---

var fibonacciNumbers = Fibonacci();

---

Ca n'exécute rien (à part affecter un objet à la variable). La méthode Fibonacci ne s'exécute au fur et à mesure que tu lis la séquence fibonacciNumbers.

donc les named indexers c'est les propriétés comme item du datareader ou controls de control si j'ai bien suivi

et le yield qui n'existe pas en vb servirait à faire des créer IEnumerable "non synchrone"

et les ienumerable du framework sont quand meme "asynchrone" en vb.net malgré le fait qu'on puisse pas en écrire ?
parce que je suis parti de ce principe là, j'ai des conditions qui se rajoute avant de les parcourir ...

Citation:

---

Envoyé par Pol63

donc les named indexers c'est les propriétés comme item du datareader ou controls de control si j'ai bien suivi

---

C'est ça. En fait Item n'est une "vraie" propriété, c'est le nom donné en VB.NET à l'indexeur du type (qui s'exprime par this[string name] en C#)

Citation:

---

Envoyé par Pol63

et le yield qui n'existe pas en vb servirait à faire des créer IEnumerable "non synchrone"

et les ienumerable du framework sont quand meme "asynchrone" en vb.net malgré le fait qu'on puisse pas en écrire ?
parce que je suis parti de ce principe là, j'ai des conditions qui se rajoute avant de les parcourir ...

---

Ben en fait c'est pas une histoire de synchrone/asynchrone, dans le sens où tout se passe sur le même thread. C'est juste que le code de l'itérateur va en fait se retrouver dans un IEnumerator<T>, qui ne sera récupéré et parcouru que lorsqu'on va énumérer la séquence avec foreach (ou autre)