je suis pour si on ajoute un caractère au début de la méthode qui spécifie que c'extension (par exemple $)
je suis pour si on ajoute un caractère au début de la méthode qui spécifie que c'extension (par exemple $)
Moi je ne retiens que ça :
* c'est illisible (mélange de styles, total patchwork)
* ça n'apporte rien
* ça rend le code ambigu
Donc contre.
Contre, pour ce qui suit:
- ça donne l'impression de programmer avec un langage procédural, et pire encore: avec un langage comme le C l'utilisation de #include<fichier.h> (bien qu'elle soit différente de import) permet d'utiliser toutes les fonctions dont le prototype est déclaré dans fichier.h alors qu'avec cette syntaxe il va falloir un import pour chaque méthode static qu'on veut appeler ce qui pourrait être ennuyeux et vraiment laid. Dans ce cas, la syntaxe ordinaire (importer le package entier ou la classe) semblerait incontournable.
L'idée semble bonne mais je vote contre car je pense que la code deviendrai vite très dur à maintenir.
Devoir regarder les imports pour savoir si la methode a été redefinie de facon globale ou alors est vraimment une methode de l'interface me semble compliqué.
Si on commence à faire genre de chose après on va vouloir des namespace pour savoir à qui appartient la méthode ...
Je m'étais abstenu de voter mais vu les explications pour et contre de chacun depuis je vote contre
Je suis contre perso, pour plein de raisons déja citées (code inmaintenable, bricolage & co. rien ne vaut une bonne vieille methode statique)
j'ai voté contre
j'ai vus que ça complique un peu l'apprentissage !
On n'est pas déjà à Java6 ? oO
@ Adiguba : créer une interface List2 alors ?
Les numéro de version sont assez complexe chez Sun
natha fait allusion à "Java 2" qui était le nom donné à Java depuis les version 1.2 à 1.5/5.0...
Ainsi cette dernière se nomme "Java 2 Platform Standard Edition 5.0"
Le problème persistera alors pour les API utilisant List, et on se retrouverait avec deux méthodes différentes (ce qui est encore plus génant à mon avis) :
Pour l'interface List :
Pour l'interface List2 :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 List<String> list = ...; Collections.sort( list );
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 List2<String> list = ...; list.sort();
Perso je trouve qu'il n'est pas évident de trouver une bonne solution à ce problème...
a++
je pense moi que c'est une bonne idée. C'est le seul moyen d'ajouter des methodes a certains objets courant (String par exemple, quand on bosse en web, il manque des tonnes de choses), sans casser la compatibilité en modifiant les interfaces.
apres, oui, si on utilise partout les extensions de méthodes, ca devient illisible, mais c'est pareil avec beaucoup de choses (generics, import static, annotations) tout permet de coder de facon assez horrible.
meme l'héritage ca peut etre horrible : qui n'est jamais tombé sur un objet qui est le 15 eme d'un arbre d"héritage et quasi incomprehensible.
par contre, utilisé avec inteligence : ca aiderait. On pourrait faire des bibliotheques ciblées (StringWebUtils par exemple, ou ListUtil) et les utiliser de facon objet.
la seule autre solution, ca serait de faire des la version 1 des librairies completes c'est pas gagné
Salut,
Je crois aussi qu'ajouter un sort dans List est assez problématique, mais je trouve que l'extension de méthode est tout aussi problématique au niveau de la lisibilité au moins.
On perd, AMHA, toute la puissance de la javadoc
F.
j'ajoute ici le post d'un C#eur qui a la meme vision que moi sur les extensions methodes (et qui avait au debut la meme vision que la majorité ici qui vote non)
why-i-changed-my-mine-about-extension-methods
Je sais bien, mais ils ont tout de même décidé de l'appeler Java6 selon le même système, en sautant Java3, 4, 5. Tellement que autant j'entends parler de Java 1.5 et Java 5 (qui sont pareils), j'entends jamais parler de Java 1.6. Ca fait longtemps que j'ai pas fait un java -version avec un JRE 6 (et ici, je n'ai à disposition que la 3 et la 5). Mais, est-ce écrit Java 1.6.XX ou Java 6 ? Et dans System.getProperty("java.version"); ?
Tout est là :
http://java.sun.com/javase/6/webnotes/version-6.html
Sinon Java 5.0 était un peu un mélange des 2 noms car il était tout autant valide de dire Java 1.5 que Java 5.0 ou Tiger.
Pour Java 6.0 la transition est faite.
Contre, sans retenue.
La méthode la plus moralement acceptable pour ajouter une méthode à une Interface de l'API standard consiste a créer une nouvelle Interface et à rendre l'ancienne deprecated (mais supportée indéfiniment).
Concernant le tri il est clair que la situation aujourd'hui n'est pas propre ! Je proposerais que List et Collection reste tel quel et que les méthodes sort de Collections deviennent deprecated.
Il resterais a ajouter ceci :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 public interface SortableCollection extends Collection { public void sort(); }Et faire des SortableArrayList, ....
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 public interface SortableList<T extends Comparable> extends SortableCollection { [...] }
Enfin j'ai pas réfléchis le truc a fond c'est juste une idée qui demande à être travaillée...
Il y a des tas de truc que l'on pourrais rendre plus propre comme ça dans l'API, et utiliser des generics partout parce que là c'est un peu le patchwork....
J'ai dans l'idée qu'outre le problème du sort() pour une List, le débat tourne plus généralement autour de la question de savoir jusqu'où un langage objet doit l'être.
c'est le l'appel de fonction à la C: printf(toto) .
Code : Sélectionner tout - Visualiser dans une fenêtre à part Collection.sort(list);
c'est l'application d'une méthode à un objet.
Code : Sélectionner tout - Visualiser dans une fenêtre à part list.sort();
J'aurais tendance dans tous les cas à préférer, de loin, la 2ème manière de faire. Cependant, List n'étant pas prévue pour ça, je me résouds à la première sans grand enthousiasme.
Toutefois, j'aime assez le principe d'enchainer des méthodes:lorsque c'est possible (personnellement je trouve ça plus clair, plutôt que moins), non pas en bricolant des imports statiques, mais en prévoyant tout simplement de retourner le type de la classe dans ses méthodes au lieu de void. Impossible pour les classes ou interfaces déjà existantes, mais rien n'empêche de les encapsuler dans une autre qui rend la chose possible.
Code : Sélectionner tout - Visualiser dans une fenêtre à part truc.hop().hip().hup();
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