Cuando escribo 'desde' (en una consulta LINQ) después de importar System.Linq namespace, se entiende como palabra clave. ¿Cómo sucede esta magia?¿Cómo se impiden las palabras clave 'from/where/select' bajo el capó en LINQ y C#?
¿Es "de" un método de extensión en algún tipo?
En la práctica, sí, las palabras clave de LINQ se asignan a los métodos de extensión. Pero en realidad, es más interesante; es, literalmente, como si los sustitutos del compilador directamente para algunos métodos clave, es decir
var qry = from cust in db.Customers
where cust.IsActive
select cust;
se convierte en:
var qry = db.Customers.Where(cust => cust.IsActive);
(si tuviéramos un no trivial de selección, que añadiría .Elija (.. .some proyección ...)
Different mapa LINQ kewords a diferentes métodos - es decir, hay OrderBy, GroupBy, ThenBy, OrderByDescending, etc.
En el caso de IEnumerable<T>/IQueryable<T>, esto luego resuelve estos a través de métodos de extensión (generalmente cortesía de Enumerable/Queryable). Sin embargo, si sus objetos consultables declararon su propio Where/OrderBy/etc, estos se usarían de preferencia.
Jon Skeet cubre esto mucho más en las últimas partes de C# in Depth. También he visto an example of Jon's donde discute algunas implicaciones realmente extrañas de esto, como llamar a métodos estáticos en un tipo.
"from" es una palabra clave de idioma (como "si" o "foreach").
Ni siquiera necesita importar System.Linq para usar "desde", pero necesita usar 3.5 framework.
Ni siquiera necesita el framework 3.5; solo necesita un conjunto adecuado de métodos. Por ejemplo, LINQBridge funciona contra .NET 2.0, y usted puede escribir C# 3.0 contra él. –
No, no es así. Necesitas C# 3.0, que no es lo mismo. LINQBridge, por ejemplo, trae LINQ-to-Objects a .NET 2.0 con C# 3.0. –
"desde" no es una palabra clave de idioma. Es un elemento de sintaxis dependiente del contexto. La diferencia queda clara cuando te das cuenta de que puedes nombrar una variable "de" (sin un @), pero no puedes nombrar una variable "si" o "foreach" (a menos que agregues un @). – Timwi
Marc Gravell tiene answered the question admirably, pero no puedo resistir la tentación de mencionar el weird things you can do with query expressions. Al compilador realmente no le importa mucho cómo encuentra un miembro "Seleccionar", o "Dónde", etc.
La forma en que el compilador traduce el código en "C# 3.0 sin expresiones de consulta" antes de hacer una compilación normal es realmente hermoso: es una forma maravillosa de introducir nuevas funcionalidades en el lenguaje, pero solo tiene un impacto en una parte aislada de la especificación.
Ya lo vinculé en ;-p (solo necesité unos segundos para rastrearlo ...) –
Y el próximo hoy en el acto doble de Marc y Jon ... –
"tus amistosos MVPs del equipo de etiquetas" ;- –
Salir de Seleccionar() es solo una optimización. Todavía requiere un Seleccionar() incluso cuando se trata de una llamada a Seleccionar (x => x); –
Sí, pero es una optimización que sí lo hace. Dejará Select in si tiene "var qry = from x en y select x" - es decir, se convierte en "var qry = y.Select (x => x)" - sin embargo, en muchos de los otros casos simples típicos lo omitirá (a menos que tenga una proyección no trivial). –