Pourquoi un tableau n'est-il pas attribuable à Iterable?

avec Java5, nous pouvons écrire:

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

ou simplement en utilisant un Iterable dans la boucle for. Ceci est très pratique.

Cependant, vous ne pouvez pas écrire une méthode générique pour itérable comme ceci:

public void bar(Iterable<Foo> foos) { .. }

et l'appelant avec un tableau car ce n'est pas un Iterable:

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

Je me demande les raisons de cette décision de conception.

Les tableaux peuvent implémenter des interfaces ( Cloneableet java.io.Serializable). Alors pourquoi pas Iterable? Je suppose que les Iterableforces ajoutent une iteratorméthode et que les tableaux n'implémentent pas de méthodes. char[]ne l'emporte même pas toString. Quoi qu'il en soit, les tableaux de références devraient être considérés comme moins qu'idéaux - utilisez le Lists. Comme le commente dfa, Arrays.asListfera la conversion pour vous, explicitement.

(Cela dit, vous pouvez faire appel cloneà des tableaux.)

Le tableau est un objet, mais ses éléments peuvent ne pas l'être. Le tableau peut contenir un type primitif comme int, auquel Iterable ne peut pas faire face. Du moins c'est ce que je pense.

Les tableaux devraient prendre en charge Iterable, ils ne le font tout simplement pas, pour la même raison que les tableaux .NET ne prennent pas en charge une interface qui permet un accès aléatoire en lecture seule par position (il n'y a pas d'interface définie comme standard). Fondamentalement, les frameworks ont souvent de petites lacunes ennuyeuses, que personne ne vaut le temps de corriger. Cela n'aurait pas d'importance si nous pouvions les réparer nous-mêmes de manière optimale, mais souvent nous ne pouvons pas.

MISE À JOUR: Pour être impartial, j'ai mentionné les tableaux .NET ne prenant pas en charge une interface qui prend en charge l'accès 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 List<T>classe:

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

Tout n'est pas encore tout à fait parfait car l'interface de liste mutable IList<T>n'hérite pas IReadOnlyList<T>:

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

Il y a peut-être un possible problème de compatibilité descendante avec un tel changement.

S'il y a des progrès sur des choses similaires dans les nouvelles versions de Java, je serais intéressé de savoir dans les commentaires! :)

Malheureusement, les tableaux ne sont pas « classassez». Ils n'implémentent pas l' Iterableinterface.

Alors que les tableaux sont maintenant des objets qui implémentent Clonable et Serializable, je pense qu'un tableau n'est pas un objet au 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).

Puisque les tableaux ont commencé comme des «presque objets» avec Java 1, il serait beaucoup trop radical de changer pour en faire de vrais objets en Java.

Le compilateur traduit en fait le for eachsur un tableau en une simple forboucle avec une variable de compteur.

Compiler les éléments suivants

public void doArrayForEach() {
    int[] ints = new int[5];

    for(int i : ints) {
        System.out.println(i);
    }
}

puis décompiler le fichier .class donne

public void doArrayForEach() {
    int[] ints = new int[5];
    int[] var2 = ints;
    int var3 = ints.length;

    for(int var4 = 0; var4 < var3; ++var4) {
        int i = var2[var4];
        System.out.println(i);
    }
}