微软将有史以来做出的所有集合可用通过LINQ？ [英] Will Microsoft ever make all collections useable by LINQ?

问题描述

我一直在使用LINQ一段时间（享受），但感觉就像我打了一个speedbump当我遇到.NET专门收藏运行（DataRowCollection，ControlCollection中）。有没有办法使用LINQ与这些专业的控制的一种方式，如果不是你认为微软将在该框架的下一个版本解决这个问题？或者，我们离开了这些迭代非LINQ的方式，或拉动项目从集合到LINQ，能集合自己呢？

I've been using LINQ for awhile (and enjoy it), but it feels like I hit a speedbump when I run across .NET specialized collections(DataRowCollection, ControlCollection). Is there a way to use LINQ with these specialized controls, and if not do you think Microsoft will address this in the next release of the framework? Or are we left to iterate over these the non-LINQ way, or pull the items out of the collection into LINQ-able collections ourselves?

推荐答案

为什么像的ControlCollection 收藏不与LINQ工作的原因是，他们不是强类型。如果没有一个元素类型LINQ不能创建强类型的方法。只要你知道类型，你可以使用铸造方法来创建一个强类型的枚举，因此与LINQ使用。例如：

The reason why collections like ControlCollection do not work with LINQ is that they are not strongly typed. Without an element type LINQ cannot create strongly typed methods. As long as you know the type you can use the Cast method to create a strongly typed enumeration and hence be used with LINQ. For example

ControlCollection col = ...
var query = col.Cast<Control>().Where(x => ...);

至于微软会永远做这些实施的IEnumerable< T> 默认情况下。我的猜测是没有在这里。之所以是这样做是一个重大更改，并可能导致预期的代码的行为。甚至干脆实施的IEnumerable<控制> 为的ControlCollection 将导致改变超载，可以解决，而且几乎可以肯定会，休息用户的应用程序。

As to will Microsoft ever make these implement IEnumerable<T> by default. My guess is no here. The reason why is that doing so is a breaking change and can cause expected behavior in code. Even simply implementing IEnumerable<Control> for ControlCollection would cause changes to overload resolution that can, and almost certainly will, break user applications.

这篇关于微软将有史以来做出的所有集合可用通过LINQ？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！