2012-08-07 15 views
14

Ho appena scoperto che NET Fx ora ha 3 interfacce utili:Perché HashSet <T> non implementa IReadOnlyCollection <T>?

  1. IReadOnlyCollection<T>
  2. IReadOnlyList<T>
  3. IReadOnlyDictionary<K,V>

E sono po 'confuso perché HashSet<T> non applicano IReadOnlyCollection<T> ? Ci sono dei motivi o Microsoft ha semplicemente dimenticato di nuovo i set?

UPD

Dopo due ore di googling ho scoperto che ci sono molte collezioni in BCL che ha .Count proprietà, ma non implementano l'interfaccia IReadOnlyCollection<T>.

UPD2

ho trovato questo post http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/b4fb991a-3f5c-4923-93d4-7cd5c004f859 e la risposta da Immo Landwerth dove he've detto dopo

Will altre collezioni oltre List <> e Dizionario <> essere aggiornato a supporta queste interfacce?

Assolutamente. Infatti, tutti i nostri tipi di raccolta integrate già attuare IReadOnlyList <> e IReadOnlyDictionary <>. Ciò significa, si possibile passare direttamente un'istanza di List, T [] o Dizionario <> a un API che accetta un IReadOnly-versione di esso.

+0

Ok, quindi perché [Elenco ] (http://msdn.microsoft.com/en-us/library/6sh2ey19 (v = vs.110)) fa? – hazzik

+0

Strano. Imho, una decisione di design incongruente. Vedi http://www.infoq.com/news/2011/10/ReadOnly-WInRT/ –

+0

dove ci sono circa ISet ? – hazzik

risposta

13

Nella versione 4.5 del framework, HashSet<T> non implementa IReadOnlyCollection<out T>.

Questa omissione è stato risolto nella versione 4.6 del framework (uscito quasi 12 mesi dopo la domanda di cui sopra è stato chiesto).

Queste correzioni sono not limited to HashSet<T>, altre raccolte come Stack<T> e Queue<T> hanno ricevuto questi miglioramenti.

La speculazione sul motivo per qualsiasi omissione è discutibile. Potrebbe trattarsi di supervisione o pressione del tempo ma, francamente, è di poca importanza. Sospetto che anche l'input diretto del team di sviluppo di Microsoft sia in qualche modo soggettivo, anche se ci piacciono gli aneddoti associati.

Problemi correlati