Vincent Brabant
Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.
Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java
Ben si justement, c'est tout la le probleme, ca ne reste que du sucre syntaxique au final on a bien une map toute simple et le compilateur qui met des cast la ou il faut dans le bytecode (en gros la ou on les mettait manuellement en java 1.4-). Donc aucune difference avec la creation d'une Map<Object, Object>.
On peut deja faire sans aucun probleme :Et ça ferait quoi ce code là ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Map anagrams = (Map<String, List<String>>)new HashMap<>();
Il est possible de caster HashMap<Object, Object> en Map<String, List<String>> et de recaster cette derniere en Map<Object, Object> . On a juste le warning habituel :
Code : Sélectionner tout - Visualiser dans une fenêtre à part Map anagrams = (Map<String, List<String>>)new HashMap();
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Note: test\TestCast.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 test\TestCast.java:24: warning: [unchecked] unchecked cast found : java.util.HashMap required: java.util.Map<java.lang.String,java.util.List<java.lang.String>> Map anagrams = (Map<String, List<String>>)new HashMap(); ^ 1 warning
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
Merci pour ces précisions bouye
Et un d'plus en moins !
Pour.
Pas de perte d'informations, pas d'ambiguités, bref que des atouts ...
Pour, la plupart des raisons invoquées me semblant tout à fait valables. Regrettons quand même les <>, qui sont sans doute pas utiles (peut être pour la lecture, et encore).
En premier lieu, utilisez un moteur de recherche.
En second lieu, postez sur le forum adéquat !
CONTRE, parce que il est déjà possible, par l'inférence automatique, de supprimer complètement les répétitions.
Ainsi, pour créer un HashMap on peut écrire simplement :
Avec, comme méthode nouv :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 HashMap<String, Integer> hash; hash = nouv();
On voit que je ne répète nulle part <String, Integer>.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 public static <A, B> HashMap<A, B> nouv() { return new HashMap<A, B>(); }
Pour exploiter cette propriété il suffirait de rajouter des méthodes de création d'bbjets génériques adéquates dans le JDK, ce qui serait nettement plus léger, et mieux, à mon avis, que de changer la syntaxe.
C'est ce que je fais déjà dans mon code, (ou à peu près), où, dans chaque classe générique que je fais, j'écris ma petite méthode statique nouv qui simplifie l'écriture.
Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.
Bah tu dois t'amuser si tu codes une classe utilitaire ayant des méthodes pour tous les cas de création de Map, Set, List, et autres types utilisant les génériques. Ça alourdi le code et niveau maintenabilité c'est pas le top non plus.
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
Bah non, son code est totalement adapté, pour n'importe quel typage de son HashMap il utilise la même fonction. Ya juste une fonction par type. Mais il ne fais plus 50 new, il n'en fait qu'un par fonction
F.
Développeur Java / Flex à Shanghai, Chine
mes publications
Mon dernier tutoriel : Messages Quit IRC : explications
La rubrique IRC recrute des redacteurs : contactez moi
Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]
Oui, heu... je suis pas Sun, moi, je vais pas m'amuser à faire une méthode pour chaque cas de création...
Au demeurant, il suffirait à Sun de les inclure dans chaque classe générique, ce qui me semble largement plus facile que de changer la syntaxe.
Mieux que Google, utilisez Sur Java spécialisé sur la plate-forme java !
Pour réaliser vos applications Java dans le cadre de prestations, forfait, conseil, contactez-moi en message privé.
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
Certes, mais d'un autre coté tu utilises rarement toutes les collections existantes dans un programme, par contre tu en instancie souvent une poignée d'une même collection
F.
Développeur Java / Flex à Shanghai, Chine
mes publications
Mon dernier tutoriel : Messages Quit IRC : explications
La rubrique IRC recrute des redacteurs : contactez moi
Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]
J'ai voté contre.
1. Par principe, je suis pour la séparation du type de la variable et du type de l'instance. J'irai meme jusqu'a imposer que le type d'une variable soit toujours une interface.
2. Si le but c'est la lisibilité alors le gain est vraiment minime. Autant carrément supprimer le mot clé new et faire des allocations facon "C":
Code java : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 HashMap<String, List<String>> anagrams;
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Pour moi, c'est exactement le contraire
Et donc je suis pour la simplification, mais contre la solution proposée. Je verrais plutôt d'un bon oeil un truc "à la" dotnet:
où toute la déclaration est après le = .
Code : Sélectionner tout - Visualiser dans une fenêtre à part var mymap = new Map<Context,Layer>();
Celà, bien sûr, uniquement quand l'écriture à simplifier comprend un type déclaré et un type instancié identiques. Dans le cas contraire, il faut conserver l'écriture actuelle.
L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.
Thorna, je suis plutôt de l'avis d'adiGuba.
Aussi, je ne comprend pas pourquoi tu peux trouver le type de création plus important que le type déclaré ?
Aurais tu des arguments pour nous faire comprendre ton point de vue ?
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.
Perso cela ne m'enchante pas
On perd toute l'abstraction des types...
J'utilise une Map, et je me fiche de son implémentation exacte. Bref la déclaration comporte tout ce dont j'ai besoin de savoir. L'appel du constructeur se contente de créer une implémentation...
Code : Sélectionner tout - Visualiser dans une fenêtre à part Map<Context,Layer> map = ...;
a++
Comme quelqu'un le dit un peu plus haut, à son avis, tous les types déclarés devraient être des interfaces.
Sans aller jusqu'à pousser le raisonnement aussi loin, ça veut quand même quelque part dire qu'on déclare par exemple un "fourre-tout" véhicule (une interface qui peut décrire aussi bien des camions que des voitures ou des vélos...) et qu'on instancie un Camion, ou un Vélo, ou une Voiture alors qu'il est interdit d'instancier un véhicule... Ce qui laisse trainer dans mon esprit l'idée que le "vrai" type est celui qu'on instancie. Bien sûr, la notion d'héritage est là pour qu'on puisse gérer partout où c'est nécessaire des véhicules, tout en sachant qu'en y regardant de plus près, il s'agit vraiment de Camion, de Vélo...
Je ne suis pas spécialiste de la théorie des langages, c'est juste un ressenti personnel, issu de 30 ans de programmation dans une bonne quinzaine de langages divers ( aahh le basic GFA, l'assembleur Z80; ... ).
Dans ce cas, pourquoi ne pas écrireOn perd toute l'abstraction des types...
J'utilise une Map, et je me fiche de son implémentation exacte. Bref la déclaration comporte tout ce dont j'ai besoin de savoir. L'appel du constructeur se contente de créer une implémentation...
Code : Sélectionner tout - Visualiser dans une fenêtre à part Map<Context,Layer> map = ...;sans préciser new map(...) ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part Map<Context,Layer> map = new (paramètres)
L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.
Parce que pour la création on a besoin de connaitre le type précis pour pouvoir le créer : va-t-on instancier une HashMap, une TreeMap, ou une autre Map ???
Par contre quand on l'utilise dans 99% des cas on n'a que faire de l'implémentation car on utilise les méthodes de base défini dans l'interface Map.
La déclaration du type de la variable est importante car on va se baser dessus pour tous les traitements effectué sur cette variable...
a++
Hello,
Je vote pour pour toutes les raisons évoquées ci-dessus.
Concernant la suppression des <>, je suis partagé.. Cela peut prêter à confusion dans le code. De plus, l'affichage de warning serait du coup plus suptile et difficile à interpréter.
@+
Fabszn
Twitter : @fsznajderman
N'oubliez pas le bouton
Comment bien poser ses questions sur le forum
Pour. J'ai bien le sentiment de n'ajouter qu'un grain de sable dans le quasi consensus sur ce debat mais je ne vois aucune raison de ne pas enrichir Java dans ce sens, compte tenu de ce que cela améliore sensiblement la lisibilité du code.
Bolla
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