为什么 F# Set 不实现 ISet？
.NET Framework 在 4.0 版本中添加了 ISet 接口。在同一版本中，F# 被添加为一流语言。 F# 提供了一个不可变的 Set<'T> 类。
对我来说，提供的不可变集将实现 ISet
我的猜测是他们不想实现一个可变的接口，但我认为这个解释站不住脚。毕竟，它们的 Map<'Key, 'Value> 类实现了 IDictionary，它是可变的。在实现接口的类框架中的其他地方也有一些示例，但这些示例仅部分适用。
我的另一个想法是 ISet 是新的，所以也许他们没有抽出时间来解决它。但这似乎有点单薄。
ISet 是通用的（v. IDictionary，但不是）这一事实与它有什么关系吗？
对此事的任何想法将不胜感激。
The .NET Framework is adding an ISet<T> interface with the 4.0 release. In the same release, F# is being added as a first-class language. F# provides an immutable Set<'T> class.
It would seem logical to me that the immutable set provided would implement the ISet<T> interface, but it doesn't. Does anyone know why?
My guess is that they didn't want to implement an interface intended to be mutable, but I don't think this explanation holds up. After all, their Map<'Key, 'Value> class implements IDictionary, which is mutable. And there are examples elsewhere in the framework of classes implementing interfaces that are only partially appropriate.
My other thought is that ISet<T> is new, so maybe they didn't get around to it. But that seems kind of thin.
Does the fact that ISet<T> is generic (v. IDictionary, which is not) have anything to do with it?
Any thoughts on the matter would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
顺便说一句，我认为我以前并不知道
ISet。 （实际上，我回顾了旧电子邮件，发现其中提到了 BCL 计划——从 2008 年开始——但就是这样。所以我认为它不在我们的关注范围内。）也就是说，F# 努力成为来源—— .NET 2.0 和 .NET 4.0 位之间兼容，以便将 .NET 4.0 实体向后移植到 FSharp.Core.dll 版本 2.0 中。例如，2.0 FSharp.Core 包含 System.Tuple、System.BigInteger、System.Threading.CancelationTokenSource（异步编程模型的一部分） ）等，并且
ISet可能是反向移植的另一项工作（不过，我不清楚是否“有必要”移植它）。我将提交一个问题来查看，尽管目前它可能没有实际意义。
Offhand I don't think I was previously aware of
ISet. (Actually I looked back through old email, and found one mention of BCL plans for it--from 2008--but that was it. So I think it wasn't on our radar.)That said, F# strives to be source-compatible between its .NET 2.0 and .NET 4.0 bits, to the point of back-porting .NET 4.0 entities into FSharp.Core.dll version 2.0. For example, The 2.0 FSharp.Core contains
System.Tuple,System.BigInteger,System.Threading.CancelationTokenSource(part of the async programming model), etc., andISetwould potentially be another bit of work to back-port (it's unclear to me if it would be 'necessary' to port it, though).I'll file an issue to have a look, though it may be moot at this point in time.
既然没有人加入，我就补充一下我的猜测。首先，
IDictionary<'k,'v>接口的大部分对于不可变字典仍然有意义；它实际上只是添加或删除不起作用的单个元素。其次，已经编写了大量依赖于 IDictionary 的代码，因此能够在该代码中使用 F# 值是一个很好的优势。另一方面，
ISet<'t>的多个方法需要变异，不仅包括添加单个元素，还包括多个集合变异运算符，例如并集和交集。此外，许多集合用例已包含在IEnumerable<'t>接口中 - 我认为人们依赖ISet<'t>的情况相对较少基于不可变集的代码的实现。我不认为通用性与之有任何关系 - 请注意，尽管有 MSDN 文档，F# 映射还是实现了通用的 IDictionary 接口，而不是非通用的接口。
Since no one else is jumping in, I'll add my speculation. First of all, the majority of the
IDictionary<'k,'v>interface still makes sense for an immutable dictionary; it's really only adding or removing individual elements that won't work. Secondly, there's a decent amount of code that has already been written which relies onIDictionary, so being able to use F# values with that code is a nice plus.On the other hand, several of
ISet<'t>'s methods require mutation, including not just adding individual elements, but also several set mutating operators such as union and intersection. Additionally, many set use cases are already subsumed by theIEnumerable<'t>interface - I think that it will be relatively rare for people to rely onISet<'t>implementations for immutable set based code.I don't think that genericity has anything to do with it - note that despite the MSDN documentation, F# maps implement the generic
IDictionaryinterface, not the non-generic one.