Building software : make it work, make it good, make it fast
Linq in action
17. June 2008
If you want to learn Linq this is the book.
Linq to objects is a misnomer
14. March 2008
Linq to objects is a misnomer. Linq to IEnumerable(of T) would be better. The idea is that, when you're writing Linq code, it should be VERY VERY easy to "grok" against what "data source" the query it's going to run.
Here's a simple example :
from s in File.RealAllLines("blah.txt")
should be written as
string lines = File.ReadAllLines("blah.txt");
var f = from s in lines
In the second case it should be clear that you reading all the contents of that file in memory and the query is running "against" a string.
LINQ query expressions differences
29. February 2008
Much to my surprise, once i started digging, it seems that the difference between the C# and VB.NET implementation of query expressions are quite big. Case in point : C# doesn't support the "distinct" clause and VB.NET does.
Also the compiler is quite "strict" when you're using expressions :
var g = from w in words where w.Length > 5 .Distinct() select w;
This seems a valid query (especially when you "map" logically query expressions to SQL) except it won't compile. It will crap out with a totally uninformative and wrong error message. On the other hand, this will compile and run just fine :
var g = from w in words .Distinct() where w.Length > 5 select w;
The point i'm trying to make is that it seems to be "easier" to write code using query operators directly instead of query expressions. The code will be longer but when you read it you won't have to switch back and forth mentally from different query expression implementations :
var g = words.Distinct().Where((string w) => w.Length > 5);
Newer posts >>