Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have something that works like a fixed size list - it's actually called FixedSizeStack<T> in my program. I will use it to represent the X last occured events. This event list will then be examined by different observers, and if they detect patterns they will trigger some action.

Naturally, I see no reason for them to know of FixedSizeStack<T> - to me it makes sense to present it to the actions as IEnumerable. I am considering giving them this event list in their constructors, then calling something like PreviewEvent(Event e); and EventOccured(); and they will iterate over this IEnumerable.

I feel a little queasy enumerating this IEnumerable multiple times, and making it part of the contract that the enumeration changes - do you think this is a reasonable method?

share|improve this question
If you can take on the dependency, you might want to consider using Rx/IObservable instead. Sounds like a perfect use case. – Steve Evers Jul 11 '12 at 20:11
up vote 8 down vote accepted

I don't think it's a code smell at all. The IEnumerable (and IEnumerable<T>) interfaces are simply described as:

Exposes the enumerator, which supports a simple iteration over a collection of a specified type. - MSDN

It's a collection, and it exposes an enumerator. There's nothing in the contract that would imply that that each time you access the enumerator, that it would return the same sequence of elements. Probably a little unconventional, but totally correct.

It is up to the consumer to make assumptions or have requirements about a reference to a collection being passed in. If the consumer really doesn't want the list to change unexpectedly, they should immediately call .ToList() or .ToArray().

share|improve this answer
Returning the list as IEnumerable is separating code through interfaces, which is always a big plus for me. – bwalk2895 Jul 11 '12 at 20:08

It would be more semantically correct to include the IEnumerable as a parameter passed to the event handler.

share|improve this answer
Very interesting, in a coincidental type of way - just two minutes ago I happened to read your discussion of pure functions on, unless that is a different Telastyn. Anyway, I'm a bit divided on how to do it, but it's very possible I'll choose this way. I'm most definately a fan of pure(ish) functions. – Max Jul 11 '12 at 17:30
@Max - I'm the only one :] – Telastyn Jul 11 '12 at 18:40
I'd be a bit careful of passing an IEnumerable through an event handler because of thread safety. If I went that way I'd put a copy of the list in the eventargs so it could be operated on without issues. Because it is a copy the original list is still protected (One reason to use IEnumerable as opposed to IList is to indicate this is a read only operation). Usual pedant disclaimer, this isn't applicable to all cases. – Ian Jul 12 '12 at 4:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.