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

Version imprimable

Voir 40 message(s) de cette discussion en une page

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;
}

19/12/2007, 02h00
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
19/12/2007, 09h23
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...
19/12/2007, 10h00
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++
19/12/2007, 10h15
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....
19/12/2007, 10h36
austin P.

contre

la lecture du code n'est pas simple
19/12/2007, 11h24
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(...) ?
19/12/2007, 11h27
bobuse

Citation:

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 ?

Citation:

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 !!
19/12/2007, 11h46
adiGuba
Citation:

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); }
:arrow: 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().

:arrow: cela permettrait une gestion plus souple...

a++
19/12/2007, 11h51
bassim

ça me rappelle le Pascal
19/12/2007, 12h22
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.
19/12/2007, 13h56
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 ;)
19/12/2007, 15h01
Napalm51

Citation:

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é.
19/12/2007, 15h39
bobuse

Citation:

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.
19/12/2007, 16h24
Jester

La surcharge d'opérateur , on va y venir ;-)
19/12/2007, 16h33
bobuse

Citation:

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.
19/12/2007, 16h38
adiGuba

Citation:

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 :arrow: 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++
19/12/2007, 17h52
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...
19/12/2007, 23h43
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.
19/12/2007, 23h52
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};

Voir 40 message(s) de cette discussion en une page