When does a library deserve the be called "Linq-something" or "something-Linq"?

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:

Is the API about data access and processing?
Does it attempt to make the access/processing fluent, ideally (but not necessarily) conforming to the query expression pattern to enable the language features of VB9 and C#3 to help with readable code?

I don't know - System.Linq does have Queryable in it that relies heavily on Expression trees and which seems to be the one that is used when "from s in list where ..." gets compiled. Without expression trees the respective IQueryProvider could not do its magic transforming the that clause.

Tobias Hertkorn 2009-03-10 09:34:08

That's used for LINQ providers which *need* to use expression trees (and which implement IQueryable, which isn't a necessity). If you use LINQ to Objects, however, that uses Enumerable instead of Queryable, and delegates instead of expression trees.

Jon Skeet 2009-03-10 09:41:19

System.Linq also has Enumerable in it, which doesn't rely on Expression trees and implements the same operators. You should read Skeet's book!

Daniel Earwicker 2009-03-10 09:41:40

@Earwicker I would argue that the Enumerable implementation (which I was aware of ;) ) is there for performance reasons. I suggest you look at EnumerableQuery. Oh, and having read a book is not an excuse to end an argument. ;)

Tobias Hertkorn 2009-03-10 11:29:56

@Jon I was not talking about Linq-to-... "Provider" libraries. Those do have the authority to choose if they expose IQueryable or IEnumerable as their results. But libraries that claim to extend Linq imho must be able to seemlessly work with both kinds of provider libraries.

Tobias Hertkorn 2009-03-10 11:33:29

@Tobias: I think you'd have to give a specific example before we could easily decide whether it's abusing the name "LINQ" or not. But I *do* think your apparent expectation that any library with the name "LINQ" in it will involve expression trees is unreasonable, and "Foo-LINQ" and (cont)

Jon Skeet 2009-03-10 11:48:13

"LINQ-to-Foo" is not a distinction which is particularly well-defined. Are you disappointed that Parallel LINQ is really aimed at LINQ to Objects?

Jon Skeet 2009-03-10 11:49:02

Aaah,too few characters. ;) PLINQ introduces IParallelEnumerable with a whole different game. And it is kinda unfortunate that LINQ is in the name. But I was really talking about libraries that imho, by using the Linq in their names, claim to extend the operation one can use on (cont)

Tobias Hertkorn 2009-03-10 14:58:54

IQueryable but are I think somewhat lazy and just extend IEnumerable. Because then LINQ Provider aren't able understand those operations and optimize for them (ExpressionVisitor). Plus I'm kinda surprised that you claim there is no def for diff. -to- libraries provide a specialized IQueryProvider.

Tobias Hertkorn 2009-03-10 15:08:05

I just don't see the implications you do: "By using the Linq in their names, claim to extend the operation one can use on IQueryable" - that's your inference, and I haven't come across anyone with the same inferences. You seem to understand LINQ to mean a very specific thing (cont)

Jon Skeet 2009-03-10 15:26:37

- IQueryable and expression trees. I view it in a much broader way, and have no problem with Parallel LINQ, my own projects or similar things using the term "LINQ". Frankly *no* library is going to be able to extend what every provider can do, because they would have to know all about all providers.

Jon Skeet 2009-03-10 15:27:40

Basically I think your expectations are unrealistic. Can you identify where those expectations come from? Why do you think that including LINQ in the name of a library means they're going to do cunning things with IQueryable?

Jon Skeet 2009-03-10 15:28:34

These 300 chars are way too limiting. I'll do a blog post after work and hopefully clarify why I see a difference and do an example of a Linq extension that imho highlights the differences. Sorry that I could not clarify it enough. Will post the URL hopefully in the next 5-8 hours.

Tobias Hertkorn 2009-03-10 16:18:00

Righto. I agree that discussion is kinda tricky in here :)

Jon Skeet 2009-03-10 16:26:39

http://saftsack.fs.uni-bayreuth.de/~dun3/archives/mapping-the-unchartered-waters-of-linq/253.html rough, ugly, too long. Hope you excuse the format of the post and the code. It was a very quick shot from the hip. Comments are of course welcome. ;)

Tobias Hertkorn 2009-03-11 01:51:36

Thanks - will comment later. You still seem to be focusing on IQueryable unnecessarily, IMO.

Jon Skeet 2009-03-11 06:35:37

ansaurus

tags:

views:

answers:

When does a library deserve the be called "Linq-something" or "something-Linq"?

related questions