L'interface c'est Map, HashMap est une des implémentations possibles. Et ça c'est juste de l'objet standard et ça ne pose aucun problème.
L'exemple pour le XML par contre, c'est vrai que c'est chiant. Par contre ça a une réelle utilité, et c'est utilisé. Ça permet de fournir d'autres implémentations (qui s'enregistrent au près de la fabrique) et qui font un travail un peu différent, ou plus rapide, ou que sait-je d'autre. Par contre c'est un peu dommage qu'il n'existe pas un masquage ou wrapper pour éviter d'écrire ce genre de choses à rallonge quand on n'est pas intéressé par le type d'implémentation précise qui sera choisi.
Il existe surtout pas mal de choses qui sont manquantes dans la grammaire Java qui peuvent être chiantes au quotidien, mais ce n'est pas du tout les exemples que tu montres.
Java 7 améliore quelques petites choses sur le langage (switch sur un type string, catch multiples, meilleure gestion des ressources systèmes ouvertes (équivalent des file descriptors), syntaxe diamond pour l'intialisation de type générique), mais on est encore très loin de la souplesse de grammaire qu'offre un langage comme Python par exemple avec ses dictionnaires, tuples et surtout toutes les méthodes qui tournent autour.
Car tout de même, dans un langage procédural (fusse-t-il objet), on a majoritairement un enchaînement de blocs de contrôles (if, while, for, switch, try catch), de manipulation arithmétique, affectations…et de manipulations ensemblistes.
Et sur ce dernier point que Java est très très loin derrière les autres langages. C'est la panacée du tout‑objet, qui fait qu'il n'existe qu'un seul type primitif de liste, qui est très très limité, et que pour le reste il faille passer par des objets/classes ensemblistes (java.util.Collection) qui ont une API très pauvres. Du coup il existe un tas de bibliothèques qui permettent d'ajouter quelques fonctionnalités ensemblistes, mais on reste sur une manipulation orientée objet, ce qui n'est pas du tout adapté pour ce cas de figure. De plus, ces librairies externes ne sont pas considérées pour une future inclusion dans le JRE, ce qui reste donc pénalisant.
Je pense qu'il existe d'autres domaines que la pauvreté du domaine ensembliste qui pourrait être cité, mais c'est vraiment celui qui me dérange au quotidien.
[^] # Re: Bof...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . En réponse au journal PHP, A Fractal Of Bad Design. Évalué à 3.
L'interface c'est Map, HashMap est une des implémentations possibles. Et ça c'est juste de l'objet standard et ça ne pose aucun problème.
L'exemple pour le XML par contre, c'est vrai que c'est chiant. Par contre ça a une réelle utilité, et c'est utilisé. Ça permet de fournir d'autres implémentations (qui s'enregistrent au près de la fabrique) et qui font un travail un peu différent, ou plus rapide, ou que sait-je d'autre. Par contre c'est un peu dommage qu'il n'existe pas un masquage ou wrapper pour éviter d'écrire ce genre de choses à rallonge quand on n'est pas intéressé par le type d'implémentation précise qui sera choisi.
Il existe surtout pas mal de choses qui sont manquantes dans la grammaire Java qui peuvent être chiantes au quotidien, mais ce n'est pas du tout les exemples que tu montres.
Java 7 améliore quelques petites choses sur le langage (switch sur un type string, catch multiples, meilleure gestion des ressources systèmes ouvertes (équivalent des file descriptors), syntaxe diamond pour l'intialisation de type générique), mais on est encore très loin de la souplesse de grammaire qu'offre un langage comme Python par exemple avec ses dictionnaires, tuples et surtout toutes les méthodes qui tournent autour.
Car tout de même, dans un langage procédural (fusse-t-il objet), on a majoritairement un enchaînement de blocs de contrôles (if, while, for, switch, try catch), de manipulation arithmétique, affectations…et de manipulations ensemblistes.
Et sur ce dernier point que Java est très très loin derrière les autres langages. C'est la panacée du tout‑objet, qui fait qu'il n'existe qu'un seul type primitif de liste, qui est très très limité, et que pour le reste il faille passer par des objets/classes ensemblistes (java.util.Collection) qui ont une API très pauvres. Du coup il existe un tas de bibliothèques qui permettent d'ajouter quelques fonctionnalités ensemblistes, mais on reste sur une manipulation orientée objet, ce qui n'est pas du tout adapté pour ce cas de figure. De plus, ces librairies externes ne sont pas considérées pour une future inclusion dans le JRE, ce qui reste donc pénalisant.
Je pense qu'il existe d'autres domaines que la pauvreté du domaine ensembliste qui pourrait être cité, mais c'est vraiment celui qui me dérange au quotidien.