Thu, March 8, 2007, 03:09 AM under
Orcas |
LINQ
At a recent event where I was presenting on
LINQ, I showed a query with a join, similar to the following:
var results =
from p in Process.GetProcesses()
join p2 in MyProccess.GetMyProcList()
on p.ProcessName equals p2.MyProcName
where p.Threads.Count > 14
orderby p.ProcessName descending
select new { p2.MyProcDescription, ThreadCount = p.Threads.Count, p.Id };
After the session one of the delegates asked me: "Why do we have to use the
equals keyword and not just
==". In other words he would have preferred to type:
on p.ProcessName == p2.MyProcNameI didn't have a good answer but promised to look into it.
Looking into it involved pinging the product team and
Matt Warren (C# software architect) came up with the reply, which I include unedited, warts and all :-)
"The reason C# has the word ‘equals’ instead of the ‘==’ operator was to make it clear that the ‘on’ clause needs you to supply two separate expressions that are compared for equality not a single predicate expression. The from-join pattern maps to the Enumerable.Join() standard query operator that specifies two separate delegates that are used to compute values that can then be compared. It needs them as separate delegates in order to build a lookup table with one and probe into the lookup table with the other. A full query processor like SQL is free to examine a single predicate expression and choose how it is going to process it. Yet, to make LINQ operate similar to SQL would require that the join condition be always specified as an expression tree, a significant overhead for the simple in-memory object case."
Makes sense!
UPDATE: Vladimir Sadov from the Visual Basic team told me that VB also uses Equals for pretty much the same reasons.