Discussion :

[vbrabant]

Aujourd'hui :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[bobuse]

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 ?

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 !!

[Napalm51]

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é.

[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

[woodwai]

Pour.
Je préférerais aussi qu'une interface permette clairement ce type de syntaxe.

Mon pour est motivé par le fait que l'utilisation de ces opérateur est déjà largement rependue dans le monde J2EE car la JSTL le fait donc pourquoi ne pas le faire en natif.

[ripounet]

Si c'est accepté un jour, il vaudrait mieux que ça impose une Interface.
Mais se pose le problème du nommage des méthodes : dans une classe on n'a droit qu'à 1 seule méthode
Toto get(Object clé)
et 1 seul
void put(Object clé, Toto valeur)
donc soit les noms choisis seront "un peu tordus" (putAtindex ?), soit ils risqueront d'enter en conflit avec d'autres noms imposés par d'autres interfaces.

[ash.ice.loky]

Pour, ainsi que pour les autres operateurs ... vive la redefinition

[Invité]

Qu'est ce que ça apporte?

Modifier le langage, pourquoi pas si ça apporte un vrai plus.

Mais là, quel est l'intérêt, c'est du détail?

[denisC]

Contre dans son etat actuel.

Soit on décide de la surcharge des opérateurs en Java, et ce genre de notation pourra en faire parti, soit on reste purement dans de l'objet avec des notations objets classiques.

Ce dérapage petit a petit ne me plait pas du tout. A mon avis, une situation intermédiaire est dangeureuse.

Donc soit syntaxe completement objet comme en Java, ou alors redefinition de tous les operateurs, comme en Python.

[Bluespear]

Contre,
pour moi ça porte à confusion avec les tableaux -> relecture difficile

[DrHelmut]

Contre.

Aucun apport, voire une regression pour l'auto-completion des IDE...

[tralloc]

Moi je trouve ça excellent et très pratique, je ne vois pas pourquoi certains trouveraient cela illisible

[natha]

Je pense que de toute façon cette fonctionnalité n'apparaîtra pas car comme il a été dit, l'utilisation des Iterators est préférable, et ajouter cette nouvelle syntaxe encouragera plutôt les développeurs à utiliser les index, ce qui serait un retour en arrière et une source supplémentaire de bugs.

Le foreach était une réelle amélioration.
Les [i] il faut oublier.

[lex2004]

Pour à 100%!

Je ne pense pas que cette fonctionnalités réduirait un temps soit peu la lisibilité du code. Au contraire, ce serait un enrichissement majeur: une syntaxe épurée pour un langage moderne. N'oublions pas que par essence, les opérateurs sont polymorphes. Par exemple, quand je parcoure mon code et que je rencontre une expression comme ceci: z = x + y, je ne pose pas la question de savoir si x, y et z sont des entiers, des flottants ou des chaînes de caractères. Le cas échéant, je n'ai qu'a laisser traîner le curseur de la souris au dessus de chaque identificateur quelques instants pour que l'IDE me renseigne sur son type. De toutes façons, ce n'est pas l'opérateur + qui me renseigne sur le type des objets auxquels il s'applique. Il en va de même pour l'opérateur []. Il pourrait être appliqué à n'importe quel type pour peu que cela ait un sens. Et avec les collections, cela a justement un sens (qui varie selon le type de collection).

[blbird]

Pour à 100%. Ayant 8 ans de Java derrière moi, et étant maintenant du côté sombre (.Net), les itérateurs (entiers, chaîne ou n'importe quel type d'ailleurs) sont géniaux à l'utilisation. Il n'y a absolument pas photo.