Reuse existing delegates

Feb 28, 2008 at 3:16 PM
I know it is only spike code, but if it's there, I believe is so you get feedback so here it is :)

I think we should leverage existing delegates such as: System.Action<T>. System.Func<T, ...>

I don't see the need for the following delegates:


In my "app framework", I already defined plenty of "default" actions that could be leveraged.
Mar 1, 2008 at 8:50 PM
Thanks for the feedback, and we will keep this in mind.
Mar 4, 2008 at 9:20 PM
There is a good argument that the Action<T> is not self documenting in the same was as Listener<TSubscriber> is.
Mar 4, 2008 at 11:16 PM
Edited Mar 5, 2008 at 4:31 PM
Building on existing knowledge is a lot more "self documenting" to me than trying to understand some new delegateS.

Just by reading "Listener<TSubscriber>" doesn't give me a clue about the delegate signature. Action<T> does. It's everywhere. So is Func<T>. In my world at least :)

I'll give you another example:

public class Person
  public bool IsOnMedicine{ get; set; }
  public int Age { get; set; }
public static class PersonExpressions
  public static Func<Person, bool> CanDrink = person => person.Age > 18 && !person.IsOnMedicine;

In the BCL, they've introduced the Predicate<T> delegate. I understand it "documents" well the intent. However, everywhere a method accepts a Predicate<T> parameter, I can say bye-bye to my existing expressions I've build for LINQ.

List<Person> persons = ...
IEnumerable<Person> personsIWantToBeWithTonight = persons.Where(PersonExpressions.CanDrink);

List<T>.FindAll(Predicate<T> predicate)
List<Person> persons = ...
List<Person> personsIWithICouldBeWithIfItCompiled = persons.FindAll(PersonExpressions.CanDrink); // Won't compile

I personally think leveraging well established delegates has great value for reuse, especially with business rules.