CODEWITHSUNDEEP
c#.netiterator
james lewis
james lewis

Reputation: 2532

Correct usage of iterator blocks

I was refactoring some code earlier and I came across an implementation of an iterator block I wasn't too sure about. In an integration layer of a system where the client is calling an extrernal API for some data I have a set of translators that take the data returned from the API and translate it into collections of business entities used in the logic layer. A common translator class will look like this:

// translate a collection of entities coming back from an extrernal source into business entities
public static IEnumerable<MyBusinessEnt> Translate(IEnumerable<My3rdPartyEnt> ents) {

    // for each 3rd party ent, create business ent and return collection
    return from ent in ents
           select new MyBusinessEnt {
               Id = ent.Id,
               Code = ent.Code
           };
}

Today I came across the following code. Again, it's a translator class, it's purpose is to translate the collection in the parameter into the method return type. However, this time it's an iterator block:

// same implementation of a translator but as an iterator block
public static IEnumerable<MyBusinessEnt> Translate(IEnumerable<My3rdPartyEnt> ents) {
    foreach(var ent in ents)
    {
        yield return new MyBusinessEnt {
            Id = ent.Id,
            Code = ent.Code
        };
    }
}

My question is: is this a valid use of an iterator block? I can't see the benefit of creating a translator class in this way. Could this result in some unexpected behaviour?

Upvotes: 8

Views: 1835

Answers (5)

Eric Lippert
Eric Lippert

Reputation: 660407

Your two samples do pretty much exactly the same thing. The query version will be rewritten into a call to Select, and Select is written exactly like your second example; it iterates over each element in the source collection and yield-returns a transformed element.

This is a perfectly valid use of an iterator block, though of course it is no longer necessary to write your own iterator blocks like this because you can just use Select.

Upvotes: 16

Aliostad
Aliostad

Reputation: 81680

The major difference is on when each code runs. First one is delayed until return value is iterated while second one runs immediately. What I mean is that the for loop is forcing the iteration to run. The fact that the class exposes a IEnumerable<T> and in this case is delayed is another thing.

This does not provide any benefit over simple Select. yield's real power is when there is a conditional involved:

foreach(var ent in ents)
{
    if(someCondition)
    yield return new MyBusinessEnt {
        Id = ent.Id,
        Code = ent.Code
    };
}

Upvotes: -1

Guffa
Guffa

Reputation: 700650

Yes, that works fine, and the result is very similar.

Both creates an object that is capable of returning the result. Both rely on the source enumerable to remain intact until the result is completed (or cut short). Both uses deferred execution, i.e. the objects are created one at a time when you iterate the result.

There is a difference in that the first returns an expression that uses library methods to produce an enumerator, while the second creates a custom enumerator.

Upvotes: 3

John Saunders
John Saunders

Reputation: 161821

The first example is not an iterator. It just creates and returns an IEnumerable<MyBusinessEnt>.

The second is an iterator and I don't see anything wrong with it. Each time the caller iterates over the return value of that method, the yield will return a new element.

Upvotes: 3

eouw0o83hf
eouw0o83hf

Reputation: 9598

Yes, that's valid. The foreach has the advantage of being debuggable,so I tend to prefer that design.

Upvotes: 3

Related Questions