Currently to me, LINQ is just a loose and amorphous cloud of concepts, usually about data access but also in combination with lambda expressions, delegates, anonymous functions and extension methods, it is about string and collection manipulation, so I want to pin it down.
When I write the following code, can I say I am "using LINQ" or not?
List<string> words = new List<string>() { "one", "two", "three" };
words.ForEach(word => Console.WriteLine(word.ToUpper()));
e.g. the "ForEach" method is widely referred to as a "LINQ method" yet its home is in System.Collections.Generic.List and not System.Linq.
It's not part of LINQ - it existed in .NET 2.0, well before LINQ. It's LINQ-like, but I wouldn't say it's part of LINQ.
On the other hand, if you implement your own IEnumerable<T>
extension method ForEach
(like in MoreLINQ) that could be regarded as a non-standard LINQ operator...
ForEach is not LINQ, it's just a method that takes a delegate. Been there since .NET 2.0.
Linq means "language integrated query". To really be "using" linq, you need a construct something like this:
var result = from word in words
where word.Length < 5
select word;
That said, the system of IEnumerable + lazy evaluation + lamdba expression + closures on which linq depends on is significant enough by itself to warrant it's own buzzword. Saying that you can use lambda expressions doesn't really cut it, imo. Case in point is this sample. You could use linq, but why when this is just as nice and much shorter:
var result = words.Where(w => w.Length < 5);
Taking a delegate does not make it LINQ.
Foreach is not a "LINQ" method, it is not a member of Enumerable
or Queryable
, and there is no comprehension syntax for it.
And, most of all, it modifies the source (list), which is not something LINQ to Objects does.
I would say "No".
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With