Detectando IEnumerable "Máquinas de Estado"

Acabo de leer un artículo interesante llamado Cómo ser demasiado lindo con retorno de rendimiento de C #

Me hizo preguntarme cuál es la mejor manera de detectar si un IEnumerable es una colección real enumerable, o si es una máquina de estado generada con la palabra clave de rendimiento.

Por ejemplo, puede modificar DoubleXValue (del artículo) a algo como:

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

Pregunta 1) ¿Hay una mejor manera de hacer esto?

Pregunta 2) ¿Es esto algo de lo que debería preocuparme al crear una API?

Su pregunta, según tengo entendido, parece estar basada en una premisa incorrecta. Déjame ver si puedo reconstruir el razonamiento:

• El artículo vinculado describe cómo las secuencias generadas automáticamente exhiben un comportamiento "perezoso" y muestra cómo esto puede conducir a un resultado contrario a la intuición.
• Por lo tanto, puedo detectar si una instancia dada de IEnumerable exhibirá este comportamiento perezoso al verificar si se genera automáticamente.
• ¿Cómo puedo hacer eso?

El problema es que la segunda premisa es falsa. Incluso si pudiera detectar si un IEnumerable dado fue el resultado de una transformación de bloque iterador (y sí, hay formas de hacerlo) no ayudaría porque la suposición es incorrecta. Vamos a ilustrar por qué.

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;
  }
}

Muy bien, tenemos cuatro métodos. S1 y S2 son secuencias generadas automáticamente; S3 y S4 son secuencias generadas manualmente. Ahora supongamos que tenemos:

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

El resultado para S1 y S4 será 0; cada vez que enumera la secuencia, obtiene una nueva referencia a una M creada. El resultado para S2 y S3 será 100; cada vez que enumera la secuencia, obtiene la misma referencia a M que obtuvo la última vez. Si el código de secuencia se genera automáticamente o no es ortogonal a la pregunta de si los objetos enumerados tienen identidad referencial o no. Esas dos propiedades, la generación automática y la identidad referencial, en realidad no tienen nada que ver entre sí. El artículo que vinculaste los combina de alguna manera.

A menos que un proveedor de secuencias esté documentado como siempre ofreciendo objetos que tienen identidad referencial , no es prudente suponer que lo hace.

Creo que el concepto clave es que debes tratar cualquier IEnumerable<T>colección como inmutable : no debes modificar los objetos a partir de ella, debes crear una nueva colección con nuevos objetos:

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

(O escriba lo mismo de manera más sucinta usando LINQ Select()).

Si realmente desea modificar los elementos de la colección, no use IEnumerable<T>, use IList<T>(o posiblemente IReadOnlyList<T>si no desea modificar la colección en sí, solo los elementos que contiene y está en .Net 4.5):

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

De esta manera, si alguien intenta usar su método IEnumerable<T>, fallará en el momento de la compilación.

Personalmente, creo que el problema resaltado en ese artículo proviene del uso excesivo de la IEnumerableinterfaz por parte de muchos desarrolladores de C # en estos días. Parece que se ha convertido en el tipo predeterminado cuando se requiere una colección de objetos, pero hay mucha información que IEnumerablesimplemente no te dice ... crucialmente: si se ha reificado o no *.

Si encuentra que necesita detectar si un IEnumerablees realmente un IEnumerableo algo más, la abstracción se ha filtrado y probablemente se encuentre en una situación en la que su tipo de parámetro es demasiado flojo. Si necesita la información adicional que IEnumerablesolo no proporciona, explique ese requisito eligiendo una de las otras interfaces como ICollectiono IList.

Editar para los downvoters Por favor regrese y lea la pregunta cuidadosamente. El OP está pidiendo una manera de garantizar que las IEnumerableinstancias se hayan materializado antes de pasar a su método API. Mi respuesta aborda esa pregunta. Hay un problema más amplio con respecto a la forma correcta de usar IEnumerable, y ciertamente las expectativas del código que el OP pegó se basan en un malentendido de ese problema más amplio, pero el OP no preguntó cómo usar correctamente IEnumerableo cómo trabajar con tipos inmutables . No es justo rechazarme por no responder una pregunta que no se hizo.

* Yo uso el término reify, otros usan stabilizeo materialize. No creo que la comunidad haya adoptado una convención común todavía.