Discussion :

[yostane]

je suis pour si on ajoute un caractère au début de la méthode qui spécifie que c'extension (par exemple $)

[Patriarch24]

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.

[Amine_sas]

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.

[The_badger_man]

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.

[elmor]

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 ...

[natha]

Je m'étais abstenu de voter mais vu les explications pour et contre de chacun depuis je vote contre

[joho]

Je suis contre perso, pour plein de raisons déja citées (code inmaintenable, bricolage & co. rien ne vaut une bonne vieille methode statique)

[zambizi]

j'ai voté contre
j'ai vus que ça complique un peu l'apprentissage !

[®om]

Totalement contre.

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

Ça serait beaucoup plus logique...

[adiGuba]

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++

[natha]

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

Pour Java 3 alors

[dingoth]

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

@ Adiguba : créer une interface List2 alors ?

[adiGuba]

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

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"

@ Adiguba : créer une interface List2 alors ?

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Pour l'interface List2 :

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++

[lunatix]

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é

[mavina]

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.

[lunatix]

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

[dingoth]

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"

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

[natha]

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.

[fatypunk]

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();
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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....

[Thorna]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Collection.sort(list);

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.