Pourquoi n'y a-t-il pas d'implémentation générique de OrderedDictionary dans .net?

Pourquoi Microsoft n'a-t-il pas fourni d'implémentation générique de OrderedDictionary?

Il y a quelques implémentations personnalisées que j'ai vues, y compris: http://www.codeproject.com/KB/recipes/GenericOrderedDictionary.aspx

Mais pourquoi Microsoft ne l'a-t-il pas inclus dans la bibliothèque .net de base? Ils avaient sûrement une raison de ne pas construire un générique ... mais qu'est-ce que c'est?

Avant de poster ce message, j'ai vu: /programming/2629027/no-generic-implementation-of-ordereddictionary

Mais cela confirme simplement qu'il n'existe pas. Pas pourquoi ça n'existe pas.

Merci

En C # 4.0 En bref, j'ai lu ceci:

1. An OrderedDictionaryest une combinaison de a HashTableetArrayList
2. Il n'y a pas de générique ArrayList
3. "La ArrayListclasse non générique est principalement utilisée pour la compatibilité descendante avec Framework 1.x ..."
4. "An ArrayListest fonctionnellement similaire à List<object>"
5. "La réflexion est plus facile avec un non générique ArrayListqu'avec un List<object>"

Conclusion?

Aucun générique OrderedDictionaryparce que sa construction sous-jacente est une classe dépréciée (officieusement) qui n'a pas de version générique elle-même.

La OrderedDictionarysurcharge de l'opération d'indexation de sorte que l'indexation avec un entier Nmettra l'élément en position N, tandis que l'indexation avec un Objectrécupérera l'élément correspondant à cet objet. Si l'on devait créer un OrderedDictionary<int, string>appel myDictet ajouter des éléments (1, "George") et (0, "Fred") dans cet ordre, devrait myDict[0]retourner "George" ou "Fred"?

Un tel problème aurait pu être résolu en imposant une contrainte de classe au type de clé. D'un autre côté, une grande partie de l'utilité des collections génériques découle de leur capacité à travailler efficacement avec les types de valeur. Imposer une contrainte de classe au type de clé semble un peu moche.

Si la classe n'avait pas à être conforme CLS mais devait simplement travailler avec vb.net, une conception judicieuse aurait pu être d'utiliser des propriétés indexées nommées. Ainsi, dans l'exemple ci-dessus, myDict.ByKey[0]aurait donné "Fred" et myDict.BySequence[0]aurait donné "George". Malheureusement, les langages comme C # ne prennent pas en charge les propriétés indexées nommées. Alors que l'on aurait pu claquer quelque chose pour permettre l'utilisation de la syntaxe ci-dessus même sans ces propriétés, la décision malheureuse d'envelopper les champs de structures comme Pointet Rectanglesignifie que pour myDict.ByKey[0] = "Wally"fonctionner, myDict.ByKeydevrait renvoyer un nouvel objet de classe. Une structure serait plus efficace, mais les compilateurs rejetteraient ce qui ressemblait à une écriture dans une structure en lecture seule (bien que la propriété ne modifie pas la structure renvoyée parByKey, mais modifiez plutôt la collection à laquelle il contient une référence).

Personnellement, je pense qu'un objet dictionnaire-ish qui a été spécifié comme gardant la trace de l'ordre d'insertion serait une bonne chose à avoir; Je voudrais également avoir un objet dictionnaire-ish qui pourrait facilement retourner la clé associée à une clé particulière (de sorte que, par exemple, si l'on a un dictionnaire qui ne respecte pas la casse et a ajouté un enregistrement avec une clé de "GEORGE", un pourrait demander au dictionnaire quelle clé est associée à "George" sans avoir à parcourir tous les KeyValuePairobjets retournés dans une énumération.

Parce que le maintien de l'ordre empêche la recherche O (1) qu'IDictionary implique, sauf si vous encapsulez deux collections (une pour la commande, une pour la recherche), ce qui rend l'ajout / la suppression moins performant et augmente l'utilisation de la mémoire. Ou vous pourriez avoir une recherche plus lente en échange d'une utilisation moindre de la mémoire.

Je suppose qu'il n'y avait pas de choix «clairement meilleur» ici, donc il n'est pas entré dans la bibliothèque standard. Surtout vers 2.0, C # apprenait encore des erreurs de Java. Je ne serais pas surpris si l'approche `` tout et l'évier de cuisine '' de Java pour les collections dans leur bibliothèque standard était également considérée comme quelque chose à éviter.