Pour
Contre
Ah effectivement j'avais mal lu . Point de probleme sur les Map alors.
Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.
suivez mon blog sur Développez.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook
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.
Venez visiter mon site sur developpez ou mon blog perso
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
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.
Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
De la bonne manière de poser une question (et de répondre).
Je ne fais pas de service par MP. Merci (...de lire les règles...).
Ma page dvp.com
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).
-"Tout ça me paraît très mal organisé. Je veux déposer une réclamation. Je paye mes impôts, après tout!"
-"JE SUIS LA MORT, PAS LES IMPÔTS! MOI, JE N'ARRIVE QU'UNE FOIS".
Pieds d'argile (1996), Terry Pratchett 1948 - 2015
(trad. Patrick Couton)
trop compliqué !
Benoit Moussaud - XebiaLabs - Automatisation des déploiements. Screencast & Demo
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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é Donc oui, on pourra toujours se servir de remove(), get(), put()...
Nous sommes tous semblables, alors acceptons nos différences !
--------------------------------------------------------------
Liens : Blog | Page DVP | Twitter
Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
Critiques : Apache Maven
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.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 : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 mmap[clé] = valeur1; mmap[clé] = valeur2;
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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.
Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.
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.
@+
Fabszn
Twitter : @fsznajderman
N'oubliez pas le bouton
Comment bien poser ses questions sur le forum
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager