about IEnumerable

[Tony Johansson]

Hello!

interface IEnumerable is declared in this way.
public interface IEnumerable<T> : IEnumerable
{
IEnumerator<T> GetEnumerator();
}

Now to my question I can't understand why the generic interface
IEnumerable<T> is implementing
the non generic interface IEnumerable ?

I mean that if I use generics I have no use for implementing public
IEnumerator GetEnumerator()
This mean that any class or struct that implement IEnumerable<T>
must implement these two see below.
public IEnumerator GetEnumerator()
{
....
}

IEnumerator<T> IEnumerable<T>.GetEnumerator()
{
....
}

//Tony

 

[Peter Duniho]

Hello!

interface IEnumerable is declared in this way.
public interface IEnumerable<T> : IEnumerable
{
IEnumerator<T> GetEnumerator();
}

Now to my question I can't understand why the generic interface
IEnumerable<T> is implementing
the non generic interface IEnumerable ?

I mean that if I use generics I have no use for implementing public
IEnumerator GetEnumerator()

Are you _sure_ you have no use for it? How have you _proven_ that?

There are still lots of places in .NET, not to mention third-party
classes, that don't use generics. It would be really awkward if you

This mean that any class or struct that implement IEnumerable<T>
must implement these two see below.

Yes, that's true. But:

public IEnumerator GetEnumerator()
{
....
}

IEnumerator<T> IEnumerable<T>.GetEnumerator()
{
....
}

Typically, you'd implement IEnumerable explicitly and IEnumerable<T>
implicitly, not the other way around. Also, the implementation of
IEnumerable is usually just a matter of returning the result of a call
to the IEnumerable<T> implementation.

It isn't really much of a hardship to implement both, and doing so
ensures that you don't run into any strange inconsistencies where you've
got an enumerable class, but you can't use it with something that
expects an enumerable class.

Pete

 

[Tony Johansson]

Hello!

What I mean is that for example the ArrayList which is a non generic class
is implementing IEnumerable which sound
reasonable but I can't as I mentioned before why the generic IEnumerable<T>
is implementing IEnumerable.

I mean a generic class/struct should implement a generic intereface but a
non generic class
should implement a non generic interface.

We know that IEnumerable<T> is implementing IEnumerable can you give a
simple
example of the usefulness of that implementation

//Tony

 

[Peter Duniho]

Hello!

What I mean is that for example the ArrayList which is a non generic class
is implementing IEnumerable which sound
reasonable but I can't as I mentioned before why the generic IEnumerable<T>
is implementing IEnumerable.

I mean a generic class/struct should implement a generic intereface but a
non generic class
should implement a non generic interface.

I don't see why that should be. Perhaps you can elaborate. To me, the
fact that the interface is generic doesn't necessarily mean it shouldn't
be used by a non-generic class. It just means the non-generic class
would have to provide a specific type argument for the interface.

For example, you might have a class that makes sense as an enumerable
only of strings, so it might be declared like this:

class StringCollection : IEnumerable<string>
{
}

Note that the class itself isn't generic, but it uses a generic
interface, and using the generic interface adds value as compared to
using a non-generic interface.

We know that IEnumerable<T> is implementing IEnumerable can you give a
simple
example of the usefulness of that implementation

I'm not entirely sure what you mean. To me, it's patently obvious that
if you have an non-generic class that only knows about IEnumerable
(perhaps it's an older one, for example), that there's still a benefit
to ensuring that newer classes taking advantage of the generic
IEnumerable<T> interface will still work with that class.

But unless IEnumerable<T> itself implements IEnumerable, it would be
possible to write a class that implements IEnumerable<T> and yet can't
be used with such a non-generic class.

Pete

 

[kndg]

[...]
We know that IEnumerable<T> is implementing IEnumerable can you give a
simple
example of the usefulness of that implementation

[...]

Hi Tony,

It is there to keep your old implementation (that use non-generic list)
works.
Consider below example;

using System;
using System.Collections;
using System.Collections.Generic;

public class MyClass
{
public static void Main(string[] args)
{
ArrayList nonGenericList = new ArrayList() { 1, 2, 3, 4, 5, 6, 7,
8, 9 };
List<int> genericList = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 };

Console.WriteLine("Output non-generic value");
ShowValue(nonGenericList);
Console.WriteLine("Output generic value");
ShowValue(genericList);
}

public static void ShowValue(IEnumerable list)
{
foreach (var p in list)
{
Console.Write(p + " ");
}
Console.WriteLine();
}
}

Since the ShowValue method expect the IEnumerable object as parameter,
you can also pass the IEnumerable<T> object since it also implement the
IEnumerable interface.

Regards.

 

[kndg]

[...]
We know that IEnumerable<T> is implementing IEnumerable can you give
a simple
example of the usefulness of that implementation

[...]

Hi Tony,

It is there to keep your old implementation (that use non-generic list)
works.
[...]

Okay, probably my above statement is not accurate.
Simple answer: "IEnumerable<T> inherits from IEnumerable because it can!"
Here is the answers from Anders Hejlsberg that was quoted on Brad Adam's
blog.

Why does IEnumerable<T> inherits from IEnumerable?
http://blogs.msdn.com/brada/archive/2005/01/18/355755.aspx

 

[Peter Duniho]

[...]

It is there to keep your old implementation (that use non-generic
list) works.
[...]

Okay, probably my above statement is not accurate.
Simple answer: "IEnumerable<T> inherits from IEnumerable because it can!"
Here is the answers from Anders Hejlsberg that was quoted on Brad Adam's
blog.

Why does IEnumerable<T> inherits from IEnumerable?
http://blogs.msdn.com/brada/archive/2005/01/18/355755.aspx

To be clear: the main thrust of that post is that there are a bunch of
other interfaces that _also_ would have inherited their non-generic
counterparts, except that they aren't variant in a way that would work.

None of that post explains why one would want any or all of them to
inherit the non-generic version. The answer to _that_ is what you and I
have both written: because doing so allows for better compatibility with
code that doesn't support the newer generic versions. Your statement
was perfectly accurate; it just doesn't explain the full picture (nor
does Hejlsberg's article...the two answers together are required to see
the full picture).

Pete