1

当您想要在 c# 中进行一组正则表达式匹配时，您会得到一个MatchCollection. 同样处理一组组和一个GroupCollection.

但是，即使在 4.5 中，它们都是非通用的，尽管它会（据我所知）：

  • 根本不破坏任何东西，因为IEnumerable<T>继承自IEnumerable.
  • 使其更易于与 LINQ 一起使用，例如，myMatchCollection.Cast<Match>().SomeLINQMethod()您可以这样做myMatchCollection.SomeLINQMethod()
  • 让它更有效率，因为你不需要一开始就施放它。
  • 根本不用为团队做太多工作。他们需要做的就是将他们的内部实现从一个更改ArrayList为一个List<Match|| Group>（见鬼，甚至像Match[]||之类的东西Group[]）并添加一个Match GetEnumerator方法，这应该不超过 5 分钟。

不过，我的问题是：我错过了什么吗？还有其他原因为什么他们不能将它们更改为通用的，并且更好地与 LINQ 一起使用？

4

2 回答 2

0
  1. 更改现有定义将是一项重大更改。
  2. 每个新功能都会产生机会成本，这会阻止实施其他一些可能更高价值的功能。
  3. 感知到的好处是（非常！？）次要的。
  4. 围绕现有实现编写自己的通用包装器是直截了当的。

如果您不同意这些论点中的任何一个，请向 Microsoft 提出他们错误地计算了收益成本确定的业务案例。他们甚至可能会倾听并实施它；你有什么损失？

于 2013-05-04T22:21:17.137 回答
0

根本不会破坏任何东西，因为 IEnumerable 继承自 IEnumerable。

可能不是。尽管每一个变化都是一个突破性的变化，但确实存在发生一些奇怪交互的风险。绝对保证没有重大更改的唯一方法是不更改任何内容。

虽然这也是不可接受的（或者在任何事情上都没有取得进展），但它是对任何改变的持续压力。

使其更易于与 LINQ 一起使用，例如代替 myMatchCollection.Cast().SomeLINQMethod() 你可以只做 myMatchCollection.SomeLINQMethod()

是的，也是我认为这可能值得做的一个原因。请注意，在可能更改为泛型和存在 linq 之间有几个框架版本。我会回到这一点。

让它更有效率，因为你不需要一开始就施放它。

您不需要对 MatchCollection 的许多用途进行强制转换，仅当您通过接口使用它时。

根本不用为团队做太多工作。他们需要做的就是将其内部实现从 ArrayList 更改为 List（地狱，甚至像 Match[]||Group[] 之类的东西）并添加一个 Match GetEnumerator 方法，这应该不会超过 5 分钟。

如您在https://github.com/dotnet/corefx/中所见，此更改是在 .NET Core 的未来分支中完成的（即对 API 的添加而不是修复、对现有代码的添加测试等）commit/9a764c6fc139dbd3f3a526ad7def52178f1c71c3有 1168 个添加和 88 个删除，这是超过 5 分钟的工作，即使没有审查它（当然有）。

请注意，不需要从 to 更改ArrayList，List<Match>因为List<Group>这已经完成了。

如果它从future变成master，它确实会带来你所说的一些好处。

但值得注意的是，即使目前，如果您遍历，MatchCollection您也不会进行强制转换（内部代码可能会或可能不会，具体取决于您使用的版本，因为 .NET Core 和 Silverlight 都已在List<Match>内部使用，而其他代码则没有't）。如果您被迫进行强制转换，则转换是相对便宜的（与包含的元素是值类型不同）。

那时，人们决定不值得为相对温和的收益而承担相对温和的风险，特别是考虑到参与其中的每个人都有其他事情要做。

在https://github.com/dotnet/corefx/issues/271上，人们认为收益确实值得冒险。请注意，仅讨论该风险涉及的人员需要超过五分钟的工作时间。

另请注意，枚举的速度并没有您想的那么快，foreach因为公众GetEnumerable()仍然IEnumerator没有返回IEnumerator<Match>，因为变化确实是一个突破性的变化。

于 2015-09-29T16:22:36.803 回答