<t> = List<t>.Find(predicate<t>) or for some code
String dogName = "Max";
List<Dog> dogs = some list of dogs;
Dog aDog = dogs.Find(delegate (Dog match)
That will return the first dog in the list that is named Max.
There are many operations you can do this way and none of this is all that new or really interesting, except I came across ForEach(Predicate<T>).
To use this, it is List<t>.ForEach(Predicate<t>).
So I found it interesting that they would include the ForEach on the list. I started a message post at work asking about this. When should you use the list ForEach vs. the regular foreach. Is one better than the other and what not.
Geoff shared that by using ForEach looping becomes a natural part of the list and it reduces the amount of code that needs to be written. Grant took it one step further in summing up Geoff's response.
He states "Imagine you want to be able to talk about solving problems using some sort of “natural” set based language. The chained delegates *do* this, and in doing so reduce boilerplate code. Still, the question of why do this at all, why bother, why does this exist, why solve problems this way exists. The answer is *list comprehensions*; and it is well worth the read."
You can find out more about List Comprehensions here.
I am not going to lie and say I understand List Comprehension fully, however my point of the story is I like that when I ask the people I work with a question about why use a ForEach instead of a foreach, the discussion ends with a lesson on list comprehension.
Now playing: Amy Winehouse - You Know I'm No Good