tags:

views:

199

answers:

4

Can't i overload List's Add method ?

class ListDemo<T>:List<T>
 {
    public override T  Add<T>(T value)
   {
      return base.Add(value);
   }
}

I am receiving the following error :

1) Type parameter 'T' has the same name as the type parameter from outer type 'CollectionsExample.ListDemo

2) 'CollectionsExample.ListDemo.Add(T)': no suitable method found to override

+3  A: 

The correct code is:

class ListDemo<T>:List<T>
{
    public new void Add(T value)
    {
      base.Add(value);
    }
}

You don't need a type parameter on both the class declaration and the method. It is the class declaration that is generic in this case; so when you try to declare the Add method as taking a generic type parameter named T, the compiler will complain that you are trying to have 2 type parameters with the same name.

Edit: Fixed the code sample. Since Add is not virtual, it cannot be overridden with the override keyword (so the original sample would actually not compile). You can still declare it using new, but that could lead to different meaning of your Add method. I would strongly consider just implementing IList<T>, as suggested in the comments.

driis
You are correct, this code will compile. But because `List.Add()` isn't declared as virtual, if you use this `ListDemo` class in code that expects a `List`, the overridden `Add()` method won't get called.
Daniel Pryden
This will warn. You should use new, not override, but that's not going to do what you expect...
Reed Copsey
-1 - this is not correct. List<T>.Add is not marked as virtual so your solution won't work.
Rob Levine
-1 - this won't compile. The Add method returns void, not T
Paul Sasik
You're right, Add is not virtual. Edited the answer.
driis
-1: Hiding `Add(T)` is a sure way to introduce nasty bugs in your application. The code will actually change behaviors based on whether it's held in a `List<T>` or `ListDemo<T>` variable, but will never warn you about which one is in use at any given time. This is a HUGE no-no.
280Z28
@280Z28, I agree, but it is the correct answer to the question. I woudl also prefer another approach.
driis
+5  A: 

Instead of subclassing from List<T>, you should encapsulate List<T> and implement IList<T>. This makes it easy to handle "overriding" the behavior of Add:

public class ListDemo<T> : IList<T>
{
    private List<T> list = new List<T>(); // Internal list
    public void Add(T item)
    {
       // Do your pre-add logic here
       list.Add(item); // add to the internal list
       // Do your post-add logic here
    }

    // Implement all IList<T> methods, just passing through to list, such as:
}

List<T> should not be part of your public API - it should be an implementation detail.

Reed Copsey
`Collection<T>` is a customizable implementation backed by a `List<T>`, so it should be seriously considered over re-rolling the code to keep it simple (and keep the focus on the parts where this implementation differs from `List<T>`).
280Z28
+1  A: 

Deriving from List<T> is almost always pointless. See my answer to this other question for a full rundown:

How to create a custom collection in .NET 2.0

280Z28
A: 

Deriving from List is not pointless if that is the class that gives you what you need. And all you want to do is add a couple methods, such as FindCar(Car dodge).

mintlucky