On Aug 5, 11:27*am, "Siegfried Heintze" <siegfr...@heintze.comwrote:
OK, you have convinced me to abandon the new LINQ lambda functions for
production code.
I do apogize - it was not my intention, and you will probably want to
reconsider this. LINQ is immensely useful in production - when used
where it is supposed to be used.
But I'm curious: could I make them work? The intellisense shows All and I
tried to make them work and I could not.
Of course you can make them work! The point was that the way you tried
to use All() was not what it was designed to solve. If you look in
MSDN, here's the description of All():
"Determines whether all elements of a sequence satisfy a condition."
For instance, if you wanted to check whether all font families in your
collection are some variations of Courier, you could do:
if (families.All(family =family.Name.Contains("Courier")) { ... }
Which is more terse then using foreach to iterate and check it
manually, and at the same time makes the intent clearer.
However, the example you've given - which simply enumerated the
families and displayed their names - is precisely what plain foreach
is intended to cover; therefore, there's no LINQ method to do it (why
duplicate?). List<Thas ForEach() (since 2.0, even before LINQ),
which is somewhat LINQish in appearance, but I never really understood
its point - it's not shorter, it's not faster, and it does the same
thing, so why bother? Apparently, LINQ designers thought the same.
In short, use LINQ methods when you need to query or transform
collections - projection, slicing, sorting, grouping etc. Use foreach
when you need to apply some action to each element of the collection
(such as printing it, saving it to a file, drawing it etc).