JDK 7: Proposition 5 : extensions de méthodes

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.

Citation:

---

Envoyé par OButterlin

Et sur quel critère tu vas trier tes objets ?!
Si c'est des numériques, c'est simple, mais si ce sont des objets complexes, tu fais comment ?

---

Et bien tu passes en paramètre de sort() le critère.

L'idée semble bonne mais je vote contre :aie: 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 :evilred:!

Totalement contre.

Citation:

---

Envoyé par yann2

Je préfère plutôt l'ajout d'une méthode sort dans l'interface List par exemple.

---

Ça serait beaucoup plus logique...

Citation:

---

Envoyé par ®om

Citation:

---

Envoyé par yann2

Je préfère plutôt l'ajout d'une méthode sort dans l'interface List par exemple.

---

Ça serait beaucoup plus logique...

---

Mais malheureusement impossible sans provoquer une perte de la compatibilité...

a++

Citation:

---

Envoyé par adiGuba

Mais malheureusement impossible sans provoquer une perte de la compatibilité...

---

Pour Java 3 alors :)

On n'est pas déjà à Java6 ? oO

@ Adiguba : créer une interface List2 alors ? :P

Citation:

---

Envoyé par dingoth

On n'est pas déjà à Java6 ? oO

---

Les numéro de version sont assez complexe chez Sun :aie:

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" :aie:

Citation:

---

Envoyé par dingoth

@ Adiguba : créer une interface List2 alors ? :P

---

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 :

Code:

---

1 2	List<String> list = ...; Collections.sort( list );

---

Pour l'interface List2 :

Code:

---

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 :D 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

Citation:

---

Envoyé par adiGuba

Les numéro de version sont assez complexe chez Sun :aie:

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" :aie:

---

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"); ?

Citation:

---

Envoyé par dingoth

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
:D

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:

---

1 2 3

public interface SortableCollection extends Collection { public void sort(); }

---

Code:

---

1 2 3

public interface SortableList<T extends Comparable> extends SortableCollection { [...] }

---

Et faire des SortableArrayList, ....

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.

Code:

---

Collection.sort(list);

---

c'est le l'appel de fonction à la C: printf(toto) .

Code:

---

list.sort();

---

c'est l'application d'une méthode à un objet.
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:

Code:

---

truc.hop().hip().hup();

---

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.

Bonjour,

Je suis contre, car cela n'apporte rien au niveau de la lisibilité d'un code ainsi construit.

Cordialement

contre , problème de lisibilité ne est pas facile

Salut,

Pourquoi pas ?
Passer d'un type retour void à un type retour autre n'impacte pas à la compatibilité, ce qui n'est pas le cas du contraire...

F.

j'ai voté contre, ça me semble juste une bidouille syntaxique pour un résultat cosmétique.
Je dis cosmétique car en l'occurence il s'agit de retomber sur quelquechose de visuellement normal car maListe.sort() est tout de même plus naturel que Collections.sort(maListe)

Tout ça pour contourner le problème de méthodes manquantes (à mon avis oubliée dans le cas du sort) dans des classes implémentant une interface qu'on ne peut plus toucher et dont le comportement a du coup été complété dans d'autres classes, Collections dans notre cas d'exemple.

solution radicale : pour le cas des List, déclarer toute l'arborescence List+Collections en deprecated pour garder la compat. et fusionner le tout correctement et on aura enfin maNouvelleListe.sort();

Ce n'est pas un oubli, puisque la classe "outils" Collections est apparue avec le framework collection dans la version 1.2, et elle possède sort(List)...

F.

Contre, résolument contre.

Malgré la pertinance des arguments avancés par lunatix, il me semble que le gain possible est faible par rapport aux risques probables.

Je fais sans doute figure de dynosaure, mais ce point rejoints d'ailleurs un des trucs que je n'aime pas dans le langage Java, a savoir
la confusion qu'il est possible de faire etre methode static et non-static.

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public class Banane {   String attribut = "Banane des Iles" ;   public static Banane createBanane() { return new Banane() ; }   public static void main(String [ ] args) { Banane b = null ; b = b.createBanane() ; System.out.println(b); }   public String toString() { return attribut ; }   }

---

Citation:

---

Envoyé par Bollagain

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur

---

Euh, je ne comprends pas ce qui te choque... Ta classe Banane est une Factory dans ce principe d'utilisation, c'est normal que ça fonctionne correctement et que ça soit possible de coder comme ça.

Citation:

---

Euh, je ne comprends pas ce qui te choque... Ta classe Banane est une Factory dans ce principe d'utilisation, c'est normal que ça fonctionne correctement et que ça soit possible de coder comme ça.

---

En fait, ce qui me choque, c'est qu'on puisse appeler une méthode static qur autre chose qu'une classe et que par conséquent, on puisse appeler une méthode (static) sur un objet null.

Cela étant dit, tu as raison, c'est tout a fait légale...

Citation:

---

Envoyé par Bollagain

Cela étant dit, tu as raison, c'est tout a fait légale...

---

Il y a un warning à la compi par défaut je crois ?
Ca suffit à rendre attentif à l'inutilité d'appeler une méthode statique sur une instance.

Bonjour,

Je suis contre, problème de lisibilité.

Cordialement,

c'est mieux

Comme écrit dans la faq, j'associe les import static de tiger à des using namespace du c++ . Moi c'est un truc que j'ai moyennement aimé. Ca a son utilité, mais ça a ses risques. C'est un truc que j'aime pas utiliser. Ca va pas changer avec l'extension de ce principe aux méthodes.
Pas super convaincu de l'importance de ça comparé au risque de confusion. Contre.

C'est vrai que ton main, Bollagain, me choque aussi :)

Citation:

---

Envoyé par mavina

Ce n'est pas un oubli, puisque la classe "outils" Collections est apparue avec le framework collection dans la version 1.2, et elle possède sort(List)...

F.

---

Je ne suis certain qu'il s'agisse d'un oubli non plus... Mais qu'importe la raison qui motiverais l'ajout de méthode, la depreciation et nouvelle définition et la seule qui soit propre !

Citation:

---

Envoyé par Bollagain

Contre, résolument contre.

Malgré la pertinance des arguments avancés par lunatix, il me semble que le gain possible est faible par rapport aux risques probables.

Je fais sans doute figure de dynosaure, mais ce point rejoints d'ailleurs un des trucs que je n'aime pas dans le langage Java, a savoir
la confusion qu'il est possible de faire etre methode static et non-static.

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public class Banane {   String attribut = "Banane des Iles" ;   public static Banane createBanane() { return new Banane() ; }   public static void main(String [ ] args) { Banane b = null ; b = b.createBanane() ; System.out.println(b); }   public String toString() { return attribut ; }   }

---

---

Ca me choque aussi mais il n'est pas possible de faire plus qu'un warning pour des raisons de compatibilité.

L'idée est très bonne, mais ça amène trop de risques de confusions.
=> contre

Par contre avec un autre "opérateur" que ".", je serais déjà plus ouvert.

Genre : list|sort();

C'est une bonne idee a ajouter des methods comme sort() a List class. Utiliser toujours ce bizarre objet Collections est... bizarre, et ajouter le sort() method ferait les List sur Java plus comme les objects vrais. Il faut que une List peut se sorter, sans acune classe exterieure. Et je suis pour les lambdas (closures) aussi, et ca ferait beaucoup de choses avec Lists plus facile (comme sur C#, LINQ).

Mais ce strings.filter(isCountryName).sort().uniq().each(printString) c'est une idee mouvaise. Java n'est pas Ruby pour faire choses comme ca. Le method sort() peut sorter la List "in situ", ou retourner une List sortee, mais ne pas les deux choses en meme temps, ca n'aurait pas de raison.

Contre,

Déjà, avec cet import statique, comment sait-on quelle classe obtient cette méthode statique? Rien n'indique que Collections.sort() sera attribué à List.

Pour ce genre de sucre synthaxique, tout le monde n'aime pas donc il suffit de le faire soi-même (si personne d'autre n'y met les doigts).
J'utilise depuis longtemps une classe GBC pour remplacer GridBadConstaints avec une utilisation en cascade :

Code:

---

new GBC(0,1).insets(2,5,2,5).fill(GBC.BOTH);

---

Effectivement List pourrait avoir une méthode statique sort() (ou plutôt une interface SortableList comme le propose fatypunk) mais cette méthode n'utilise rien de l'interface List. C'est pourquoi à mon avis elle est externalisée dans Collections afin de ne pas surcharger List en méthodes. C'est la même chose pour

Code:

---

Arrays

---

et aussi

Code:

---

StringUtils

---

(excellente classe de Apache).