JDK 7: Proposition 9 : Notation de tableau pour List et Map -> Intégrée [Débat]

[vbrabant]

Aujourd'hui :

Code :

1
2
3
4
5
6
void swap(List<String> list, int i, int j) {
    String s1 = list.get(i);
    list.set(i, list.get(j));
    list.set(j, s1);
}

Code :

1
2
3
4
5
6
7
8
9
10
Map<Input,Output> cache = …;
Output cachedComputation(Input in) {
    Output out = cache.get(in);
    if (out == null) {
        out = computation(input);
        cache.put(in, out);
    }
    return out;
}

Demain :

Code :

1
2
3
4
5
6
void swap(List<String> list, int i, int j) {
    String s1 = list[i];
    list[i] = list[j];
    list[j] = s1;
}

Code :

1
2
3
4
5
6
7
8
9
10
Map<Input,Output> cache = …;
Output cachedComputation(Input in) {
    Output out = cache[in];
    if (out == null) {
        out = computation(input);
        cache[in] = out;
    }
    return out;
}

[yann2]

Bonsoir

Et comment ça serait implémenté derrière ? C'est une redéfinition de l'opérateur [] ou c'est une fonctionnalité qui se limite aux listes et map ?

Dans le cas de la première réponse : pourquoi pas ?
Pour la deuxième réponse : POUR !!!

Merci

Yann

[Napalm51]

J'ai voté contre, non pas que le principe me déplaise, mais au niveau lecture/compréhension du code, ça deviendrai chaud ... Surtout dans l'exemple ci-dessus, le put() de Map permet d'ajouter OU de remplacer un couple clé/valeur, et dans le cas de l'ajout, ça deviendrait étrange (pour moi) de l'écrire de cette façon...

[adiGuba]

Pour, à condition que cela implique l'implémentation d'une interface spécifique (comme ce fut le cas pour le "for each" avec Iterable).

a++

[zulot]

Ca sent le melange des tableaux à la lecture du code pour peu que deux variables ai des noms proches....

Je m'abstient car pas vraiment pour mais je peux pas dire que je suis contre.
En C on peut faire de la redefinition d'operateur....

[austin P.]

contre

la lecture du code n'est pas simple

[OButterlin]

Pour, par contre je ne comprends pas le bémol de adiGuba...
Pour la permutation dans la liste, il me semble intéressant de pouvoir faire

Code :

1
2
3
4
 
Object tmp = list[i];
list[i] = list[j];
list[j] = tmp;

A ce sujet, à quand la méthode swap(...) ?

[bobuse]

Envoyé par Napalm51

Surtout dans l'exemple ci-dessus, le put() de Map permet d'ajouter OU de remplacer un couple clé/valeur, et dans le cas de l'ajout, ça deviendrait étrange (pour moi) de l'écrire de cette façon...

Tu as failli m'avoir, mais je pense que tu te méprends ! Dans une map, tu n'as qu'une clé pour une valeur. Ainsi lors d'un put pour ajouter un couple, si la clé est déjà présente, la valeur présente est remplacé par la nouvelle. Non ?

Envoyé par adiGuba

Pour, à condition que cela implique l'implémentation d'une interface spécifique (comme ce fut le cas pour le "for each" avec Iterable).

Hmmm, effectivement
Ça devient intéressant, mais est-ce que ce n'est pas un peu risqué ?
Boarf, je trouve pas d'exemple en fait, et c'est pas pire que le foreach

Donc zou, pour !!

[adiGuba]

Envoyé par OButterlin

Pour, par contre je ne comprends pas le bémol de adiGuba...

En fait je souhaiterais que cela ne se limite pas aux List et Map, mais que cela puisse être utilisé pour n'importe quelle classe qui implémenterait une interface spécifique.

Par exemple :

Code :

1
2
3
4
public interface IndexedType<E> {
	public E get(int index);
	public E set(int index,  E element);
}

Toutes les classes qui implémentent cette interface pourront être utilisées avec les crochets, sans pour autant implémenter List.

Bien sûr l'interface List étendra cette interface (cela ne posera aucun problème car elle comporte déjà ces méthodes) afin que cela fonctionne sur toutes les Lists...




De la manière à ce qui a été fait pour le "for each". En réalité le "for each" n'attend pas une Collection mais un Iterable, qui définit seulement la méthode iterator().

cela permettrait une gestion plus souple...


a++

[bassim]

ça me rappelle le Pascal

[eclesia]

Contre, je preferes la syntaxe actuelle qui rappelle bien plus qu'on manipule un object. redefinir les methodes put/get ... devient ambigue si on se met a manipuler les collections comme des tableaux.

[bulbo]

Contre,

On se dirige un peu trop vers de la surcharge d'opérateurs et je hais ce truc.
Mauvaise lecture: bonjour pour faire le lien avec la javadoc correspondant a l'appel par exemple.
Gain: que du sucre syntaxique, n'apporte vraiment rien d'autre.

Bulbo

[Napalm51]

Envoyé par bobuse

Tu as failli m'avoir, mais je pense que tu te méprends ! Dans une map, tu n'as qu'une clé pour une valeur. Ainsi lors d'un put pour ajouter un couple, si la clé est déjà présente, la valeur présente est remplacé par la nouvelle. Non ?

Oui c'est cela, c'est ce que je disais, enfin peut être pas en bons termes :p Mais justement remplacer le put() par un simple map[clé] = valeur me fait peur dans le cadre d'une nouvelle clé.

[bobuse]

Envoyé par Napalm51

Oui c'est cela, c'est ce que je disais, enfin peut être pas en bons termes :p Mais justement remplacer le put() par un simple map[clé] = valeur me fait peur dans le cadre d'une nouvelle clé.

C'est exactement la même chose que pour une liste en fait. Dans le cas d'une liste ou d'un array, la clé est l'indice, si tu affectes un élément à un indice ou il en a déjà un, tu remplaces l'ancien, c'est tout.

[Jester]

La surcharge d'opérateur , on va y venir ;-)

[bobuse]

Envoyé par Jester

La surcharge d'opérateur , on va y venir ;-)

Non, je ne pense pas. Ici il ne s'agit pas de surcharge d'opérateur, mais de syntaxe.

[adiGuba]

Envoyé par bobuse

Ici il ne s'agit pas de surcharge d'opérateur, mais de syntaxe.

Ben c'est quand même de la surcharge d'opérateur : pour l'opérateur [] sur des liste appeler get() ou set() selon le contexte...


Mais bon cela reste relativement bien encadré et on est loin des surcharges dans tous les sens qu'il est possible de faire en C++

Mais c'est sûr que cela pourrait avoir des effets indésirables (l'opérateur + dans une boucle en est un exemple frappant).

a++

[sinok]

Enfin dans une version complêtement différente et orientée TableModel serait de pouvoir faire çà sur des beans dont on définirait l'ordre à grand coup d'annotations.

Au niveau des listes çà me semble un peu plus foireux au niveau lecture de code, ne plus savoir si j'ai une Collection ou un tableau 100 lignes plus bas...

[bouye]

Oui MAIS non seulement il faut integrer une interface Indexable, mais il faudra egalement ammender la doc de List (avertissement que les perfs peuvent varier suivant le type de liste) et LinkedList (precision en insistant LOURDEMENT sur la lenteur des acces via [] - similaires a ceux de get() et set()). De meme la doc de Map (avertissement que les resultats peuvent varier suivant le type de map) et HashMap (precision pour indiquer que deux appels successifs a myMap[i] peuvent ne pas retourner le meme element si un nouvel element a ete insere dans la map car l'ordre de stockage varie en fonction de la methode de hashage) doit etre ammendee. Quant a TreeMap, l'indice sera fonction de l'ordre de tris, j'imagine.
Etc... Donc a manier avec precaution.

[nicorama]

J'aimerais plutot un truc qui permet d'ajouter directement des objets à la création.
Comme

Code :

ArrayList list=new ArrayList(){obj1, obj2, obj3};