Veloz,
Personally, I like returning an interface (IList<T>) better than
List<T>. I like this as a general rule, and not just for collections. If
you return an interface, you have a number of options in terms of
implementation (from changing the implementation, to swapping it outright if
you want to) which you don't have with returning concrete implementations.
For IList<T>/List<T> implementations, there isn't anything that List<T>
implements over IList<T> which is absolutely essential. If you need some of
those other operations, you can return List<T>, but you have to remember
that you are possibly returning a reference to the internal implementation,
and you are exposing operations on that reference (which IList does as well,
but a little more so with the concrete implementation).
And remember, you can always take the elements in the IList<T>
implementation and put them in a new List<T> implementation (through the
constructor, which takes an IEnumerable<T> instance, which IList<T> is).

Signature
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
> Hi there
>
[quoted text clipped - 36 lines]
>
> Michael
Doug Semler - 24 Sep 2007 18:59 GMT
On Sep 24, 1:23 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> Veloz,
>
[quoted text clipped - 57 lines]
>
> > Any thoughts on this???
About the only caveat I have to Nicholas' statement is when you need
to serialize the function result (e.g., a web service or remoting
call) you're going to want to use a concrete class instantiation (I
prefer Collection<T>, it hides pretty much all of the implementation
details)