Pourquoi un tableau ne peut-il être assigné à Iterable?

avec Java5 on peut écrire:

Foo[] foos = ... for (Foo foo : foos) 

ou simplement utiliser une Iterable dans la boucle for. C’est très pratique.

Cependant, vous ne pouvez pas écrire une méthode générique pour ce type d’itération:

 public void bar(Iterable foos) { .. } 

et l’appelant avec un tableau car ce n’est pas une itération:

 Foo[] foos = { .. }; bar(foos); // comstack time error 

Je m’interroge sur les raisons de cette décision de conception.

Les tableaux peuvent implémenter des interfaces ( Cloneable et java.io.Serializable ). Alors pourquoi pas Iterable ? Je suppose que les forces iterator ajoutant une méthode iterator et les tableaux n’implémentent pas de méthodes. char[] ne remplace même pas toSsortingng . Quoi qu’il en soit, les tableaux de références doivent être considérés comme moins qu’idéaux. Comme dfa commente, Arrays.asList effectuera la conversion pour vous, explicitement.

(Cela dit, vous pouvez appeler clone sur des tableaux.)

Le tableau est un object, mais ses éléments peuvent ne pas l’être. Le tableau peut contenir un type primitif comme int, que Iterable ne peut pas gérer. Au moins c’est ce que je pense.

Les tableaux doivent prendre en charge Iterable , mais ils ne le font pas, pour la même raison que les baies .NET ne prennent pas en charge une interface permettant un access aléatoire en lecture seule par position (il n’existe pas d’interface standard). Fondamentalement, les frameworks ont souvent de petites lacunes ennuyeuses, ce qui ne vaut pas le temps de réparer. Peu importe que nous puissions les réparer nous-mêmes de manière optimale, mais souvent nous ne le pouvons pas.

MISE À JOUR: Pour être impartiale, j’ai mentionné les baies .NET ne supportant pas une interface prenant en charge l’access aléatoire par position (voir aussi mon commentaire). Mais dans .NET 4.5, cette interface exacte a été définie et est prise en charge par les tableaux et la classe List :

 IReadOnlyList a = new[] {1, 2, 3, 4}; IReadOnlyList b = new List { 1, 2, 3, 4 }; 

Tout n’est pas encore parfait car l’interface de liste mutable IList n’hérite pas d’ IReadOnlyList :

 IList c = new List { 1, 2, 3, 4 }; IReadOnlyList d = c; // error 

Peut-être y a-t-il une compatibilité descendante possible avec un tel changement.

S’il y a des progrès sur des choses similaires dans les nouvelles versions de Java, cela m’intéresserait de savoir dans les commentaires! 🙂

Malheureusement, les tableaux ne sont pas « class -enough». Ils n’implémentent pas l’interface Iterable .

Alors que les tableaux sont désormais des objects qui implémentent Clonable et Serializable, je pense qu’un tableau n’est pas un object dans le sens normal du terme et n’implémente pas l’interface.

La raison pour laquelle vous pouvez les utiliser dans les boucles for-each est que Sun a ajouté du sucre syntatique pour les tableaux (c’est un cas particulier).

Étant donné que les tableaux ont commencé comme «presque des objects» avec Java 1, il serait beaucoup trop radical de les transformer en objects réels en Java.