Detecting IEnumerable “State Machines”

I just read an interesting article called Getting too cute with c# yield return

It made me wonder what the best way is to detect whether an IEnumerable is an actual enumerable collection, or if it’s a state machine generated with the yield keyword.

For example, you could modify DoubleXValue (from the article) to something like:

private void DoubleXValue(IEnumerable<Point> points)
{
    if(points is List<Point>)
      foreach (var point in points)
        point.X *= 2;
    else throw YouCantDoThatException();
}

Question 1) Is there a better way to do this?

Question 2) Is this something I should worry about when creating an API?

Your question, as I understand it, seems to be based on an incorrect premise. Let me see if I can reconstruct the reasoning:

The linked-to article describes how automatically-generated sequences exhibit a “lazy” behaviour, and shows how this can lead to a counter-intuitive result.
Therefore I can detect whether a given instance of IEnumerable is going to exhibit this lazy behaviour by checking to see if it is automatically generated.
How do I do that?

The problem is that the second premise is false. Even if you could detect whether or not a given IEnumerable was the result of an iterator block transformation (and yes, there are ways to do that) it wouldn’t help because the assumption is wrong. Let’s illustrate why.

class M { public int P { get; set; } }
class C
{
  public static IEnumerable<M> S1()
  {
    for (int i = 0; i < 3; ++i) 
      yield return new M { P = i };
  }

  private static M[] ems = new M[] 
  { new M { P = 0 }, new M { P = 1 }, new M { P = 2 } };
  public static IEnumerable<M> S2()
  {
    for (int i = 0; i < 3; ++i)
      yield return ems[i];
  }

  public static IEnumerable<M> S3()
  {
    return new M[] 
    { new M { P = 0 }, new M { P = 1 }, new M { P = 2 } };
  }

  private class X : IEnumerable<M>
  {
    public IEnumerator<X> GetEnumerator()
    {
      return new XEnum();
    }
    // Omitted: non generic version
    private class XEnum : IEnumerator<X>
    {
      int i = 0;
      M current;
      public bool MoveNext()
      {
        current = new M() { P = i; }
        i += 1;
        return true;
      }
      public M Current { get { return current; } }
      // Omitted: other stuff.
    }
  }

  public static IEnumerable<M> S4()
  {
    return new X();
  }

  public static void Add100(IEnumerable<M> items)
  {
    foreach(M item in items) item.P += 100;
  }
}

All right, we have four methods. S1 and S2 are automatically generated sequences; S3 and S4 are manually generated sequences. Now suppose we have:

var items = C.Sn(); // S1, S2, S3, S4
S.Add100(items);
Console.WriteLine(items.First().P);

The result for S1 and S4 will be 0; every time you enumerate the sequence, you get a fresh reference to an M created. The result for S2 and S3 will be 100; every time you enumerate the sequence, you get the same reference to M you got the last time. Whether the sequence code is automatically generated or not is orthogonal to the question of whether the objects enumerated have referential identity or not. Those two properties — automatic generation and referential identity — actually have nothing to do with each other. The article you linked to conflates them somewhat.

Unless a sequence provider is documented as always proffering up objects that have referential identity, it is unwise to assume that it does so.

I think the key concept is that you should treat any IEnumerable<T> collection as immutable: you shouldn’t modify the objects from it, you should create a new collection with new objects:

private IEnumerable<Point> DoubleXValue(IEnumerable<Point> points)
{
    foreach (var point in points)
        yield return new Point(point.X * 2, point.Y);
}

(Or write the same more succinctly using LINQ Select().)

If you actually want to modify the items in the collection, don’t use IEnumerable<T>, use IList<T> (or possibly IReadOnlyList<T> if you don’t want to modify the collection itself, only items in it, and you’re on .Net 4.5):

private void DoubleXValue(IList<Point> points)
{
    foreach (var point in points)
        point.X *= 2;
}

This way, if someone attempts to use your method with IEnumerable<T>, it will fail at compile time.

I personally think the problem highlighted in that article stems from overuse of the IEnumerable interface by many C# developers these days. It seems to have become the default type when you’re requiring a collection of objects – but there’s a lot of information that IEnumerable simply doesn’t tell you… crucially: whether or not it has been reified*.

If you find that you need to detect whether an IEnumerable is truly an IEnumerable or something else, the abstraction has leaked and you’re probably in a situation where your parameter type is a little too loose. If you require the extra information that IEnumerable alone doesn’t provide, make that requirement explicit by choosing one of the other interfaces such as ICollection or IList.

Edit for the downvoters
Please go back and read the question carefully. The OP is asking for a way to ensure that IEnumerable instances have been materialized before being passed to his API method. My answer addresses that question. There is a wider issue regarding the proper way to use IEnumerable, and certainly the expectations of the code the OP pasted are based on a misunderstanding of that wider issue, but the OP did not ask how to correctly use IEnumerable, or how to work with immutable types. It’s not fair to downvote me for not answering a question which was not posed.

* I use the term reify, others use stabilize or materialize. I don’t think a common convention has been adopted by the community just yet.

Filed under: softwareengineering - @ 23:11

Thẻ: api-design, c++

Thiết kế website giá rẻ

Danh mục

Detecting IEnumerable “State Machines”