Why do you think Microsoft wants us to go through IEnumerable to get to IEnumerator? Isn't the presence or absence of a valid cast to IEnumerator for a given type enough to determine if the type is enumerable or not?
For example whats wrong with the following?
class MyClass : IEnumerator
{
...
}
MyClass myObj = new MyClass();
if(myObj as IEnumerator != null)
{
Console.WriteLine("myObj is enumerable");
}
else
{
Console.WriteLine("myObj doesn't support enumeration");
}
You might have two threads enumerating - each needs its own enumerator.
IEnumerable.GetEnumerator returns an enumerator that is initially positioned before the first element of the collection. If you only had IEnumerator, you'd have to remember to reset yourself before using it, even in a single-threaded scenario.
An IEnumerator holds state information necessary to perform enumeration, such as array index etc.
The enumeration state information is NOT part of the enumerable object, therefore casting would not be powerful enough.
Also, the enumerator/enumerable separation allows several enumerations to be performed simultaneously on the same enumerable collection.
It is a matter of seperating responsibilities, IEnumerable is a class that can be iterated over IEnumerator is a class that does the iteration.
The accepted answer talks about multi-threading, but single-threaded algorithms would be severely limited as well. Remembering to reset the list to the start wouldn't be a problem with foreach to help you, but suppose you wanted to compare every item on the list with every other item:
int matchCount = 0;
foreach (var x in myList)
{
foreach (var y in myList)
{
if (x == y)
matchCount++;
}
}
matchCount /= 2;
If the "current position" was stored inside the list object, both inner and outer loops would be fighting over the same location to store their current position. Presumably the inner loop would run once, and then the outer loop would exit, having found itself to be past the end of the list.