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

[yann2]

Bonsoir

Envoyé par bouye

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.

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

[bouye]

Ah effectivement j'avais mal lu . Point de probleme sur les Map alors.

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

[benwit]

D'accord avec abiguba en ajoutant une interface Indexable.

Envoyé par bouye

il faut integrer une interface Indexable.

[natha]

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.

[Deadpool]

Envoyé par natha

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

[bmoussaud]

trop compliqué !

[Alec6]

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)

[bassim]

Envoyé par 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};

par contre ça, ça peut être pratique

[adiGuba]

Envoyé par bassim

par contre ça, ça peut être pratique

Cela pourrait se faire sans modifier le langage en ajoutant un constructeur/varargs à chaque implémentation de Collection, par exemple pour ArrayList :

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

En attendant on peut faire cela en 2 lignes :

Code :

1
2
ArrayList<T> list=new ArrayList<T>();
Collections.addAll(list, obj1, obj2, obj3);

a++

[xavlours]

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.

[kpouer]

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() ?

[romaintaz]

Envoyé par kpouer

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é Donc oui, on pourra toujours se servir de remove(), get(), put()...

[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

[Uther]

Envoyé par Deadpool

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

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.

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 ?

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

[Muscador]

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?

[dingoth]

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

Code :

1
2
mmap[clé] = valeur1;
mmap[clé] = valeur2;

serait lui réellement illisible pour l'usage qu'on en fait, contrairement à

Code :

1
2
mmap.put(clé,valeur1);
mmap.put(clé,valeur2);

[abriotde]

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.

[fabszn]

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.