Java: pourquoi ne pas itérer sur un itérateur?

J'ai lu Pourquoi Java est Itérateur pas un objet iterable? et Pourquoi ne sont pas les Énumérations Itératif?mais je ne comprends toujours pas pourquoi ce:

void foo(Iterator<X> it) {
  for (X x : it) {
    bar(x);
    baz(x);
  }
}

n'était pas possible. En d'autres termes, à moins que je me manque quelque chose, le ci-dessus pourrait avoir été agréable et valide sucre syntaxique pour:

void foo(Iterator<X> it) {
  for (X x; it.hasNext();) {
    x = it.next();
    bar(x);
    baz(x);
  }
}

source d'informationauteur noamtm

  1. 7

    mais je ne comprends toujours pas pourquoi ce [...] n'était pas possible.

    Je vois plusieurs raisons:

    1. Iterators ne sont pas réutilisables, donc un pour/chaque consomme de l'itérateur - pas de comportement incorrect, peut-être, mais pas intuitif pour ceux qui ne savent pas comment le pour/chaque est délactosé.
    2. Iterators n'apparaissent pas "nu" dans le code tous que, souvent, de sorte qu'il serait compliquer la JLS avec peu de gain (pour/chaque construction est assez mauvais comme il est, le travail sur les deux Iterables et tableaux).
    3. Il y a un simple solution de contournement. Il peut sembler un peu du gaspillage d'allouer un nouvel objet juste pour cela, mais l'allocation est pas cher comme il est et de s'échapper de l'analyse de vous débarrasser de ce petit coût dans la plupart des cas. (Pourquoi ils n'ont pas inclure cette solution de contournement dans un Iterables classe utilitaire, analogue à Collections et Arraysest au delà de moi, cependant).
    4. (Probablement pas le cas, voir les commentaires.) il me semble que la JLS ne pouvez référencer choses dans java.lang[citation nécessaire]de sorte qu'ils auraient à créer un Iterator interface dans java.lang qui java.util.Iterator s'étend sans rien ajouter. Maintenant, nous avons deux fonctionnellement équivalent itérateur interfaces. 50% de le nouveau code à l'aide de nu itérateurs sera de choisir le java.lang version, le reste l'utilisation de l'un dans java.util. Le Chaos qui s'ensuit, des problèmes de compatibilité abondent, etc.

    Je pense que les points 1 à 3 sont très en ligne avec la façon dont le langage Java philosophie de conception semble aller: Ne pas surprendre les nouveaux, ne compliquons pas les spec si elle n'a pas un gain certain qui éclipse les coûts, et de ne pas le faire avec une langue en fonction de ce qui peut être fait avec une bibliothèque.

    Les mêmes arguments pourraient expliquer pourquoi java.util.Enumeration n'est pas Iterabletrop.

  2. 17

    Probablement la raison pour cela est parce que les itérateurs ne sont pas réutilisables; vous devez obtenir une nouvelle Itérateur de l'Itératif de collecte à chaque fois que vous souhaitez effectuer une itération sur les éléments. Cependant, comme un correctif rapide:

    private static <T> Iterable<T> iterable(final Iterator<T> it){
     return new Iterable<T>(){ public Iterator<T> iterator(){ return it; } };
}

//....
{
     //...
     //Now we can use:
     for ( X x : iterable(it) ){
        //do something with x
     }
     //...
}
//....

    Cela dit, la meilleure chose à faire est de simplement passer à travers le Iterable<T> interface au lieu de Iterator<T>

  3. 6

    La for(Type t : iterable) syntaxe est uniquement valable pour les classes qui implémentent Iterable<Type>.

    Un itérateur ne pas mettre en œuvre itératif.

    Vous pouvez effectuer une itération sur des choses comme Collection<T>List<T>ou Set<T> parce qu'ils mettent en œuvre Itératif.

    Le code suivant est équivalent:

    for (Type t: list) {
    //do something with t
}

    et

    Iterator<Type> iter = list.iterator();
while (iter.hasNext()) {
    t = iter.next();
    //do something with t
}

    La raison pour laquelle ce n'était pas possible, c'est parce que la for-each a été ajouté à la langue à l'abstraction de la Iterator. Faire la boucle for-each travail avec les itérateurs ne serait pas accomplir ce que la boucle for-each a été créé pour.

  4. 3

    En fait, vous le pouvez.

    Il est très court, une solution disponible sur java 8:

    for (X item : (Iterable<X>) () -> iterator)

    Voir Comment itérer avec boucle foreach sur java 8 flux pour l'explication détaillée de l'affaire.

    Et quelques explications pourquoi ce n'était pas pris en charge nativement peut être trouvé dans la question liée à:

    Pourquoi ne Stream<T> ne pas mettre en œuvre Itérable<T>?

  5. 2

    Les itérateurs ne sont pas censés être réutilisés (c'est à dire: utilisé dans plus d'une itération de la boucle). En particulier, Iterator.hasNext() garantit que vous pouvez appeler en toute sécurité Iterator.next() et, en effet, obtenir la valeur suivante de la collection sous-jacente.

    Quand même itérateur est utilisé dans les deux simultanément en cours d'exécution itérations (supposons un multi-threading scénario), cette promesse ne peut plus être maintenu:

    while(iter.hasNext() {
   //Now a context switch happens, another thread is performing
   //   iter.hasNext(); x = iter.next();

  String s = iter.next();  
          //A runtime exception is thrown because the iterator was 
          //exhausted by the other thread
}

    De tels scénarios briser complètement le protocole proposé par l'Itérateur. En fait, ils peuvent se produire même dans un seul thread programme: une boucle d'itération appelle une autre méthode qui utilise la même itérateur pour effectuer ses propres itération. Lorsque cette méthode retourne, l'appelant est l'émission d'un Iterator.next() appel qui, encore une fois, échoue.

  6. 0

    Parce que la for-each est conçu pour lire quelque chose comme:

    for each element of [some collection of elements]

    Un Iterator n'est pas [some collection of elements]. Un tableau et un Iterable est.