¿Por qué no tener un empadronador .NET bidireccional?

Question

Se ha pedido un par de veces en Entonces, ¿cómo se puede implementar un empadronador bidireccional ( aquí , aquí ). Mi pregunta no es ¿Cómo (que es trivial para la mayoría de los casos), pero ¿Por qué existe tal tipo en la plataforma .NET.

public interface IBidirectionalEnumerator<T> : IEnumerator<T>
{
    bool MovePrev();
}

Obviamente, hay muchos tipos de colección que no puede implementar esto, como MoveNext() es destructivo o cambia el estado de la colección subyacente. Pero a la inversa, muchos tipos pueden implementar esta forma trivial (List, IList, LinkedList, array).

¿Por qué hay tal tipo existen?

Answer 1

• IEnumerator apoya la declaración c # foreach, así como construcciones en bucle de otros idiomas.
• No hay ninguna declaración o lenguaje de programación común que permite IBidirectionalEnumerator.

Answer 2

Cuando se está diseñando un marco, hay que tomar decisiones acerca de hacer cosas en diferentes niveles de abstracción. La desventaja es que si usted elige para exponer las cosas a un alto nivel de abstracción, logrará la generalización a costa de perder el control de grano fino sobre las cosas. Si elige para exponer cosas en niveles de abstracción más bajos, su concepto se no se puede generalizar así, pero se puede controlar datos en un nivel inferior.

Es una decisión de diseño. La implementación de ambos serán costosos y que el marco más hinchado y que necesitará para apoyar tanto al agregar características. Tendrá que mantener la compatibilidad hacia atrás en el futuro. No es una cosa sabia que añadir todo lo que se pueda imaginar para el BCL sin asegurarse de que tiene un beneficio significativo.

Answer 3

Porque, o nadie pensó en ello, ni nadie pensó que sería particularmente útil o porque no había suficiente presupuesto o ...

En realidad no es necesario, ¿verdad? Se puede implementar fácilmente por sí mismo. Tal vez el equipo BCL pensó que no valía la pena el dolor de la implementación, pruebas, documentación, etc. Nunca subestime el costo de una característica, que puede sonar "fácil", pero tiene costos.

Particularmente porque una sola interfaz que nadie implementos parecería extraño, ¿verdad? Que se puede esperar de lista, etc. matriz para implementar la interfaz, lo cual es un montón de trabajo en el final.

Answer 4

  

Obviamente, hay muchos tipos de colección que no se puede poner en práctica esto, como MoveNext() es destructivo o cambia el estado de la colección subyacente.

MoveNext() no es destructivo. De hecho, si se cambia el estado de la colección subyacente entre el momento en que el IEnumerator fue creado y el MoveNext() vez que se llama, la llamada a MoveNext() fallará.

El propósito de IEnumerator es iterar sobre todos los elementos de una colección de una vez, con el fin nativa de la colección si la colección tiene un orden nativo. IEnumerator no pretende ser un dispositivo de colección de navegación, tales como uno podría encontrar en C ++.

Answer 5

Además, ¿cuál sería la motivación para esto? Soporte de idiomas para la iteración "hacia atrás"?

El iterador no da mucho peso al concepto de "direccionalidad" de un conjunto de elementos. Es un modelo simple para proporcionar una interfaz sencilla para iterar sobre un conjunto.

Answer 6

Una gran pregunta es ¿por qué no implementa .Net IReadableByIndex, que a su vez ser heredado por IList. Tal tipo habría añadido nada a la obra necesaria para producir implementaciones IList de lectura y escritura, y habría reducido el trabajo requerido para producir implementaciones de sólo lectura (que implementaría IReadableByIndex, en lugar de IList).

No es muy útil para ponderar dichas "por qué" s, sin embargo. Net es lo que es. La única manera de remediar la situación de la red 5.0 sería permitir que un medio de declarar que una interfaz que implementa una propiedad de lectura y escritura se puede considerar que implícitamente implementar una versión de sólo lectura (de manera que permita IList a heredar una covariante IReadableByIndex sin tener que agregar un método Get explícita).