IEnumerable semantics

[elvis_the_king]

Hi all,

I am asking myself wheter IEnumerable has any inherent semantics? The
docs seem to be very unclear to me.

More specifically: When using a "foreach(...)" construct to enumerate a
Stack, Queue oder ArrayList using the IEnumerable interface - can I
safely make any assumptions about the order in which the elements are
returned? That is, LIFO for a Stack, FIFO for a queue and an order
corresponding to the indices when using an ArrayList?

Or does IEnumerable just guarantee that it will enumerate all elements
(with no specific, i. e. implementation-dependant order)?

TIA,
Matthias

[Marcus Andrén]

On 24 Sep 2005 15:20:48 -0700, "el************@web.de"
<el************@web.de> wrote:

Hi all,

I am asking myself wheter IEnumerable has any inherent semantics? The
docs seem to be very unclear to me.

More specifically: When using a "foreach(...)" construct to enumerate a
Stack, Queue oder ArrayList using the IEnumerable interface - can I
safely make any assumptions about the order in which the elements are
returned? That is, LIFO for a Stack, FIFO for a queue and an order
corresponding to the indices when using an ArrayList?

IEnumerable itself is just an interface that allows iteration through
a list of items. Any implementation of IEnumerable is free to select
their own order. Hashtable implements IEnumerable even though it is
completly unordered.

Unless the documentation for a specific implementation says anything
specific about the order you can't be guaranteed anything.

I would however be very surprised if ArrayList returned items in any
other order than from first to last. Queue and Stack is another matter
though, since neither of those have any concept of first and last
element.

--
Marcus Andrén

[elvis_the_king]

I have some methods that perform operations where the result is a
particular order of objects. These methods make use of Stack or Queue,
but that is an implementation detail. The correct resulting order is
determined by dequeuing or popping, but I would like to hide that from
the caller.

Now I asked myself if returning the IEnumerable provided by whatever
implementing collection type I choose to use is sufficient, or if I
should copy the "correct" order to an ArrayList and return the
IEnumerable of that?

Or even return that ArrayList itself - interestingly, even for
ArrayList there seem to be no guarantees about the order:
http://msdn.microsoft.com/library/en...ratorTopic.asp

(Ok, I could still write my own implementation of IEnumerable that can
be initialized with a Stack or Queue or ArrayList and would make sure
by calling pop, dequeue or whatever that the order is that way I want
it to be... but hey, programmers should be lazy, shouldn't they ;)?)

Thanks,
Matthias

[elvis_the_king]

Well, one more aspect:

IEnumerator types should not modify the underlying collection, as
several clients are allowed to use different enumerators to iterate
through the same collection concurrently. This works as long as the
collection is not modified.

Thus, the enumerator must not be implemented in a way that makes use of
pop(), dequeue() etc on the underlying collection. Now that prevents me
from writing suitable enumerators myself.

Moreover, iterating through a collection requires knowledge on how to
access the "next" element (2nd one from the stack top, queue front),
but that is clearly up to the implementation of the collection.

So the collection implementor is the only one who can guarantee the
enumerator to work in a certain way.

Although ArrayList, Queue and Stack *seem to* behave as expected when
enumerating, this is clearly something that should be addressed by the
specification.

Opinions?

Matthias