title: .NET EventHandlers - Generic or no?
body: <p>Every time I start in deep in a C# project, I end up with lots of events that really just need to pass a single item.  I stick with the <code>EventHandler</code>/<code>EventArgs</code> practice, but what I like to do is have something like:</p>
  
  <pre><code>public delegate void EventHandler&lt;T&gt;(object src, EventArgs&lt;T&gt; args);
  
  public class EventArgs&lt;T&gt;: EventArgs {
  
    private T item;
  
    public EventArgs(T item) {
      this.item = item;
    }
  
    public T Item {
      get { return item; }
    }
  }
  </code></pre>
  
  <p>Later, I can have my</p>
  
  <pre><code>public event EventHandler&lt;Foo&gt; FooChanged;
  
  public event EventHandler&lt;Bar&gt; BarChanged;
  </code></pre>
  
  <p>However, it seems that the standard for .NET is to create a new delegate and <code>EventArgs</code> subclass for each type of event.  Is there something wrong with my generic approach?
  <hr/>
  EDIT: The reason for this post is that I just re-created this in a new project, and wanted to make sure it was ok.  Actually, I was re-creating it as I posted.  I found that there is a generic <code>EventHandler&lt;TEventArgs></code>, so you don't need to create the generic delegate, but you still need the generic <code>EventArgs&lt;T></code> class, because <code>TEventArgs: EventArgs</code>.
  <hr/>
  Another EDIT: One downside (to me) of the built-in solution is the extra verbosity:</p>
  
  <pre><code>public event EventHandler&lt;EventArgs&lt;Foo&gt;&gt; FooChanged;
  </code></pre>
  
  <p>vs.</p>
  
  <pre><code>public event EventHandler&lt;Foo&gt; FooChanged;
  </code></pre>
  
  <p>It can be a pain for clients to register for your events though, because the System namespace is imported by default, so they have to manually seek out your namespace, even with a fancy tool like Resharper...  Anyone have any ideas pertaining to that?</p>