I just looked at one of those libraries that is of the naming schema ‘something-Linq’ expecting to gain some more knowledge on how to construct expression trees in an elegant way – and was disappointed. Because all I could find were methods that extended IEnumerable – of course with ‘normal’ C# code.
Now I have this question: Do non-expression extensions for IEnumerable really justify the name of the library to have ‘Linq’ in it? Or is the author just jumping on a hype trying to get more downloads for his IEnumerable extension library and I was right in expecting IQueryable and expressions when seeing ‘Linq’ in the name of the library?
Edit:
I would argue that there is a difference between Linq-to-… and something-Linq libraries. IMHO Linq-to-… are linq provider libraries, something-Linq are linq extensions. I think Linq provider libraries may choose if they expose IQueryable or IEnumerable in their results – linq extensions do not have that choice. As far as I am concerned they must be able to work with both kinds of provider libraries. That means for me that all linq extensions must provide both Queryable and Enumerable extensions.
Edit 2:
A very lively discussion took place between Jon and me in the comments of his answer. I volunteered to create a blogpost to hopefully clarify things: Mapping the uncharted waters of LINQ
Edit 3:
For anybody who is interested in the discussion – I really encourage you to go to my blog post. Skip the post itself because it is horrible – and go straight to the discussion and explanations by Jon.
LINQ doesn’t imply expression trees to me. It implies data access in the general style of LINQ. LINQ to Objects doesn’t have any expression trees in it, but is still definitely LINQ IMO.
LINQ to XML is a bit more specious – it’s really just an XML API which exposes
IEnumerable<T>in various ways, both as input and output. That means it works really well with LINQ to Objects, but it’s not implementing any of the standard operators itself. However, you do typically use it with LINQ to Objects, and the result is ‘LINQ-like’ code, so I guess it’s not too bad.I certainly have no problem with non-expression extensions being called LINQ-to-whatever – indeed, such a stance would be hypocritical given my MoreLINQ and Push LINQ projects.
To me there are two main questions: