Bonsoir
Il me semble que dans le cas d'une Map on n'utiliserait pas un indice entier mais une clé (n'importe quel objet donc), non ? Donc on s'en fout de l'ordre de stockage. Ce n'est pas ce que dit l'exemple ?
yann
Version imprimable
Ah effectivement j'avais mal lu :P. Point de probleme sur les Map alors.
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.
Contre.
Pas vraiment d'argument, ça me plait pas c'est tout. Ca oblige d'aller voir le type manipulé de départ pour savoir si c'est une List ou un tableau, j'aime pas trop scroller quand je vérifie du code. :)
Ben franchement un tableau ou une List, ça se gère presque pareil. Moi je proposerais même d'ajouter ce qu'il faut aux tableaux pour qu'ils puissent être utilisés comme n'importe quelle Collection, car un tableau ce n'est qu'une Collection particulière de taille fixe (implémentation de l'interface Collection et pourquoi pas ajout d'une sous interface concernant les collections de taille fixe).
trop compliqué !
C'est vrai qu'on remarque un problème d'unification des opérateurs.
Une classe c'est un peu comme une hashmap à la base, avec le nom des variables pour clé.
Je peux écrire maClass.maVariable
pourquoi dans une HasMap je ne peux pas écrire maHashMap.maKey
et monTableau.3 ou maList.8
On parle en réalité de chemins non ?
Vous allez me répondre il manque l'opérateur isDeclared (genre instanceOf)
Cela pourrait se faire sans modifier le langage en ajoutant un constructeur/varargs à chaque implémentation de Collection, par exemple pour ArrayList :
En attendant on peut faire cela en 2 lignes :Code:
1
2
3
4
5
6
7 public ArrayList(E first, E...args) { this(args.length + 1); add(first); for (E element : args) { add(element); } }
a++Code:
1
2 ArrayList<T> list=new ArrayList<T>(); Collections.addAll(list, obj1, obj2, obj3);
Contre, pour des raisons que bouye a évoqué.
L'API actuelle incite à utiliser les Iterators, qui sont le moyen le plus rapide de parcourir une Collection. Cette proposition, appliquée à une LinkedList (ou à une TreeMap), remplace next() en temps constant par un get(i) en temps polynomial (logarithmique pour les TreeMap).
De plus, j'ai déjà dit sur les switches que je n'aime pas trop mélanger syntaxe et API, que ce mélange devrait se limiter aux fonctions de la classe Object (comme + et toString, ou peut-être un jour switch et equals). Je trouve le foreach, qui s'applique aux Iterables ET aux tableaux, déjà un peu limite. Je n'ai pas encore changé d'avis.
En tout cas il faudrait pas que ca fasse comme en c++ que ca ajoute un élément dès qu'on accède a une clef de la liste ou de la map ...
Et comment ferait on un remove d'une clef d'ailleurs ? on conserve la méthode remove() ?
Toutes les propositions dont on débat aujourd'hui sont des ajouts, voire des raccourcis syntaxiques... En aucun cas cela ne supprime les fonctionnalités (et donc les méthodes) présentes aujourd'hui ! Sinon bonjour la compatibilité :aie: Donc oui, on pourra toujours se servir de remove(), get(), put()...
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.
Pour, ainsi que pour les autres operateurs ... vive la redefinition
Dans l'utilisation faite par le programmeur, peut-être. Mais techniquement, il y a de sacrées différences. A mon avis, il ne faut pas mélanger ces concepts.
Mon dieu, quelle horreur. Les points sont sencés porter sur des éléments déclarés dans une classe et je ne souhaite en aucun cas les voir servir à autre chose(déjà que j'hésite sur son utilisation pour les properties), même si c'est vrai que la notion de Map s'y porte plutot bien.Citation:
pourquoi dans une HasMap je ne peux pas écrire maHashMap.maKey
et monTableau.3 ou maList.8
On parle en réalité de chemins non ?
C++ qui permet de redéfinir presque tout, n'autorise par à redéfinir le point.
Après avoir longtemps hésité, je dirais plutôt non car je pense qu'il faut éviter d'avoir des syntaxe commune pour des opérations différentes comme dans certains langages ou parfois on se demande vraiment ce qu'on est en train de manipuler.
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?
Pour... avec une nuance.
J'utilise des multimaps et dans ce cas précis, je ne vois pas comment implémenter l'interface correctement : le code mmap[clé] = valeur ajouterait ou remplacerait l'élément courant ?
Là où les méthode put() et set() ont leur spécificité (dans une multimap), écrire
serait lui réellement illisible pour l'usage qu'on en fait, contrairement àCode:
1
2 mmap[clé] = valeur1; mmap[clé] = valeur2;
Code:
1
2 mmap.put(clé,valeur1); mmap.put(clé,valeur2);
Pour.Ca simplifie les get. C'est quand même plus clair
function[in]=out;
que
function(in, out); ou l'on ne sait pas qui va dans quoi et si in est modifier au passage.
Hello,
Je suis plutot contre, Je trouve aussi que celà risque d'amener de la confusion (tableau/list) à la lecture du code... et aussi le lien avec de la Javadoc peut devenir difficile.
Cette amélioration n'apporte pas grand chose d'un point de vue technique.
L'introduction du forEach était une innovation plus intéressante.:mouarf: