Warum implementiert das F # Set nicht ISETT?

8

Das .NET Framework fügt der Version 4.0 eine ISet<T> -Schnittstelle hinzu. In derselben Version wird F # als erstklassige Sprache hinzugefügt. F # stellt eine unveränderliche Set<'T> -Klasse zur Verfügung.

Es erscheint mir logisch, dass die bereitgestellte unveränderliche Menge die ISet<T> -Schnittstelle implementieren würde, aber nicht. Weiß jemand warum?

Meine Vermutung ist, dass sie keine Schnittstelle implementieren wollten, die veränderbar sein sollte, aber ich denke nicht, dass diese Erklärung Bestand hat. Immerhin implementiert ihre Map<'Key, 'Value> -Klasse IDictionary , was änderbar ist. Und es gibt Beispiele an anderer Stelle im Rahmen von Klassen, die Schnittstellen implementieren, die nur teilweise geeignet sind.

Mein anderer Gedanke ist, dass ISet<T> neu ist, also sind sie vielleicht nicht dazu gekommen. Aber das scheint irgendwie dünn.

Hat die Tatsache, dass ISet<T> generisch ist (v. IDictionary , was nicht der Fall ist) irgendetwas damit zu tun?

Irgendwelche Gedanken zu diesem Thema wären willkommen.

    
Sean Devlin 01.04.2010, 19:03
quelle

2 Antworten

5

Ich glaube nicht, dass I vorher auf ISet geachtet hat. (Tatsächlich schaute ich zurück durch alte E-Mails und fand eine Erwähnung von BCL-Plänen dafür - ab 2008 - aber das war es. Also ich denke, es war nicht auf unserem Radar.)

Das heißt, F # ist bestrebt, quellkompatibel zwischen seinen .NET 2.0- und .NET 4.0-Bits zu sein, bis hin zur Zurückportierung von .NET 4.0-Entitäten in FSharp.Core.dll, Version 2.0. Zum Beispiel enthält der 2.0 FSharp.Core System.Tuple , System.BigInteger , System.Threading.CancelationTokenSource (Teil des asynchronen Programmiermodells) usw., und ISet wäre möglicherweise ein weiterer Arbeitsschritt, um Backport zu machen (es ist unklar für mich, wenn es "notwendig" wäre, es zu portieren.)

Ich werde ein Problem einreichen, um einen Blick darauf zu werfen, obwohl es zu diesem Zeitpunkt möglicherweise nicht möglich ist.

    
Brian 02.04.2010, 04:48
quelle
5

Da niemand sonst reinspringt, füge ich meine Spekulationen hinzu. Zunächst macht die Mehrheit der Schnittstelle IDictionary<'k,'v> noch Sinn für ein unveränderliches Wörterbuch; Es werden nur einzelne Elemente hinzugefügt oder entfernt, die nicht funktionieren. Zweitens gibt es eine anständige Menge an Code, der bereits geschrieben wurde, der auf IDictionary angewiesen ist, also ist es ein nettes Plus, F # -Werte mit diesem Code zu verwenden.

Auf der anderen Seite erfordern mehrere Methoden von ISet<'t> eine Mutation, darunter nicht nur das Hinzufügen einzelner Elemente, sondern auch mehrere festgelegte Mutationsoperatoren wie Vereinigung und Schnittpunkt. Darüber hinaus werden bereits viele Anwendungsfälle durch die Schnittstelle IEnumerable<'t> subsumiert - ich denke, dass es relativ selten sein wird, dass sich Leute auf ISet<'t> Implementierungen für unveränderlichen, auf Mengen basierenden Code verlassen.

Ich glaube nicht, dass Generizität etwas damit zu tun hat - beachten Sie, dass trotz der MSDN-Dokumentation F # -Karten die generische IDictionary -Schnittstelle implementieren, nicht die nicht-generische.

    
kvb 01.04.2010 20:07
quelle

Tags und Links