为什么在 C# 中有 HashSet 而没有 Set? [英] Why have HashSet but not Set in C#?
问题描述
我的理解是 C# 在某种意义上具有 HashSet 和 set 类型.我了解 HashSet 是什么.但是为什么 set 是一个单独的词呢?为什么不是每个集合都是HashSet?
My understanding is that C# has in some sense HashSet and set types. I understand what HashSet is. But why set is a separate word? Why not every set is HashSet<Object>?
为什么C#没有通用的Set类型，类似于Dictionary类型?从我的角度来看，我想要一个具有标准查找/添加/删除性能的集合.我不太关心它是用哈希还是其他东西实现的.那么为什么不创建一个集合类，在这个版本的 C# 中实际实现为 HashSet，但在未来的版本中可能会有所不同?
Why does C# has no generic Set type, similar to Dictionary type? From my point of view, I would like to have a set with standard lookup/addition/deletion performance. I wouldn't care much whether it is realized with hashes or something else. So why not make a set class that would actually be implemented as a HashSet in this version of C# but perhaps somewhat different in a future version?
或者为什么不至少接口ISet?
Or why not at least interface ISet?
感谢以下回答的所有人:ICollection 实现了您对 ISet 的许多期望.不过，从我的角度来看，ICollection 实现了 IEnumerable 而集合不必是可枚举的——例如:1 到 2 之间的实数集(甚至更多，集合可以动态生成).我同意这是一个小小的抱怨，因为普通程序员"很少需要不可数的集合.
Learned thanks to everyone who answered below: ICollection implements a lot of what you'd expect from ISet. From my point of view, though, ICollection implements IEnumerable while sets don't have to be enumerable --- example: set of real numbers between 1 and 2 (even more, sets can be generated dynamically). I agree this is a minor rant, as 'normal programmers' rarely need uncountable sets.
好的，我想我明白了.HashSet 绝对应该被称为 Set 但单词 Set 在某种意义上是保留的.更具体地说，.NET 架构的创建者希望为不同的语言提供一致的类集(原文如此！).这意味着标准类的每个名称都不能与 .NET 语言中的任何关键字重合.然而，Set 这个词在 VB.NET 中使用，它实际上是不区分大小写的(是吗?)，所以很遗憾那里没有可操作的空间.
Ok, I think I get it. HashSet was absolutely meant to be called Set but the word Set is reserved in some sense. More specifically, creators of .NET architecture wanted to have a consistent set (sic!) of classes for different languages. This means that every name of the standard class must not coincide with any keyword in the .NET languages. The word Set, however, is used in VB.NET which is actually case-insensitive (is it?) so unfortunately there is no room for maneuvre there.
谜团解开了:)
Alex Y. 的新答案链接到 MSDN 页面 描述了即将推出的 .NET 4.0 接口 ISet，它的行为与我认为的差不多，由 HashedSet 实现.好结局.
The new answer by Alex Y. links to the MSDN page which describes the upcoming .NET 4.0 interface ISet which behaves pretty much as I thought it should and is implemented by HashedSet. Happy end.
推荐答案
(你原来关于set的问题已经回答了.IIRC，set"是英文中含义最不同的词语言...显然这对计算也有影响.)
(Your original question about set has been answered. IIRC, "set" is the word with the most different meanings in the English language... obviously this has an impact in computing too.)
我认为 HashSet<T> 使用该名称很好，但我当然欢迎 ISet<T> 接口.鉴于 HashSet<T> 仅出现在 .NET 3.5 中(这本身就令人惊讶)，我怀疑我们最终可能会获得更完整的基于集合的类型的集合.特别是，维护插入顺序的 Java LinkedHashSet 等价物在某些情况下会很有用.
I think it's fine to have HashSet<T> with that name, but I'd certainly welcome an ISet<T> interface. Given that HashSet<T> only arrived in .NET 3.5 (which in itself was surprising) I suspect we may eventually get a more complete collection of set-based types. In particular, the equivalent of Java's LinkedHashSet, which maintains insertion order, would be useful in some cases.
公平地说，ICollection<T> 接口实际上涵盖了您在 ISet<T> 中想要的大部分内容，所以这可能不是必需的.但是，您可能会争辩说，集合的核心目的(主要是关于包含，并且只是与能够迭代元素无关)与集合并不完全相同.这很棘手.事实上，一个真正的数学集合可能是不可迭代或不可数的——例如，你可以拥有1 到 2 之间的实数集合".如果你有一个任意精度的数值类型，计数将是无限的，并且迭代它没有任何意义.
To be fair, the ICollection<T> interface actually covers most of what you'd want in ISet<T>, so maybe that isn't required. However, you could argue that the core purpose of a set (which is mostly about containment, and only tangentially about being able to iterate over the elements) isn't quite the same as a collection. It's tricky. In fact, a truly mathematical set may not be iterable or countable - for instance, you could have "the set of real numbers between 1 and 2." If you had an arbitrary-precision numeric type, the count would be infinite and iterating over it wouldn't make any sense.
同样，将添加"到集合中的想法并不总是有意义的.命名集合时，可变性是一件棘手的事情:(
Likewise the idea of "adding" to a set doesn't always make sense. Mutability is a tricky business when naming collections :(
好的，回复评论:关键字 set 绝不是 Visual Basic 的遗留问题.这是设置属性值的操作，与检索操作的get相比.这与将集合作为操作的想法无关.
Okay, responding to the comment: the keyword set is in no way a legacy to do with Visual Basic. It's the operation which sets the value of a property, vs get which retrieves the operation. This has nothing to do with the idea of a set as an operation.
想象一下，关键字实际上是 fetch 和 assign，例如
Imagine that instead the keywords were actually fetch and assign, e.g.
// Not real code!
public int Foo
{
fetch
{
return fooField;
}
assign
{
fooField = value;
}
}
那里的目的明确吗?现在 real 在 C# 中的等价物只是
Is the purpose clear there? Now the real equivalent of that in C# is just
public int Foo
{
get
{
return fooField;
}
set
{
fooField = value;
}
}
所以如果你写:
x = y.Foo;
这将使用属性的 get 部分.如果你写:
that will use the get part of the property. If you write:
y.Foo = x;
这将使用 set 部分.
这样更清楚吗?
这篇关于为什么在 C# 中有 HashSet 而没有 Set?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
