Discussion :

[OButterlin]

Idem, comme bulbo, si c'est pour rendre le code incohérent, autant s'en passer...

[verbose]

J'ai voté contre. A la base, je n'aime pas trop les imports static. Je suis favorable à toute avancé qui apporterait une meilleure lisibilité au code et je ne crois pas que cette proposition aille dans ce sens.

[mavina]

Contre, allez reprendre un code en vous demandant

tiens, la fonction bidule dans List je connaissais pas, jvais aller voire dans la javadoc

et ne pas la trouver, et perdre du temps à remarquer qu'en fait c'était une sorte d' "import static" de ce type...

C'est à s'arracher les cheveux et on perd toute la puissance de la documentation javadoc

F.

[nicorama]

Contre pour les raisons citées, auxquelles je n'aurait jamais pensé. Lorsque j'ai utilisé la fonction pour la première fois, j'ai galéré à comprendre que maListe.sort() n'était pas possible, alors que c'est telement naturel.

Si c'est trop compliqué maintenant, ben tant pis.

[benwit]

Je pensai voté contre pour beaucoup de bonnes raisons citées mais je vais voté pour si on peux faire ce que dis Lunatix. Il ne restera plus qu'à l'utiliser à bon escient.

De plus ca permetrait de faire plus facilment des api de type DSL (voir mon blog , l'api quaere
et qui n'a jamais eu envie d'ajouter une bonne quinzaine de methodes a String (par exemple quand on fait du web, plutot que de tapper

Code :

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

1
2
3
maString.escapeHTML() 
plutot que 
StringUtils.escapeHTML(maString)

donc j'ai voté oui, parce que bien utilisé c'est tres puissant, et ca améliore la lisibilité du code. Mal utilisé... c'est horrible

[natha]

Je m'abstiens de voter !

+1
Je trouve que l'explication d'adiGuba est juste. Ca laisse un sentiment de bidouillage au final.

[Keihilin]

Contre.

J'étais déjà contre les extensions de méthodes dans C# (mais il ne m'ont pas écouté les bougres ).

Mêmes raisons que beaucoup : lisibilité et cohérence.

[woodwai]

Contre.

Problème de lisibilité du code.
Surtout que les IDE masquant les import, on regarde rarement les import d'une classe donc on ne verrait pas l'import static de la méthode.

[bmoussaud]

Pour ! au moins pour pouvoir ecrire:

Code :

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

1
2
 
list.sort()

Je ne comprend pas que l'on doive passer par une classes pour effectuer ce type d'opération. En revanche, utiliser un 'import static' pour arriver à ce résultat n'est peut etre pas la bonne voie

[OButterlin]

Je ne comprend pas que l'on doive passer par une classes pour effectuer ce type d'opération.

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 ?

[mbaumeler]

Contre,
ça rend le code illisible et du coup ingérable.
Merci la maintenance si c'est une autre personne qui est l'auteur original...

[lunatix]

J'étais déjà contre les extensions de méthodes dans C# (mais il ne m'ont pas écouté les bougres )

ca risquait pas me semble que c'est necessaire pour implementer LINQ.

[Keihilin]

ca risquait pas me semble que c'est necessaire pour implementer LINQ.

Il ne me semble pas. Tu confonds sûrement avec les expressions lambda

Edit :

Non, en fait tu as raison. Les extensions de méthodes sont utilisées par Linq dans plusieurs cas...
Ca ne m'avait pas sauté aux yeux de prime abord car ce n'est pas obligatoire de les utiliser, mais dans ce scénario précis, les extensions sont d'une grande élégance...

Fin du hors sujet...on parle Java ici, pas C#

[Traroth2]

Contre. C'est le bordel, le code devient illisible, et en creusant, je pensse qu'on doit pouvoir trouver des cas où la grammaire du langage devient ambigue.

[mbaumeler]

Contre. C'est le bordel, le code devient illisible, et en creusant, je pensse qu'on doit pouvoir trouver des cas où la grammaire du langage devient ambigue.

Pas besoin d'aller très loin...
Je me fais un propre type de List qui lui a un methode sort:

Code :

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

1
2
3
4
5
class MyList extends ArrayList {
    public void sort(){
        //Je fais ce que je veux
    }
}

Qu'est ce qui serait appelé dans ce cas avec:

Code :

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

1
2
3
 
    MyList maList = new MyList();
    maList.sort();

???

[ReaM]

c'est la confusion,
on pourrait croire que sort() appartiendrait à l'interface List

mais j'attends d'autres avis pour voter

Contre pour la même raison.

[xavlours]

Contre. En y ajoutant des classes et des méthodes génériques et homonymes, on peut aboutir à un sacré bazar (voire à des ambiguités ?).

[lunatix]

Les extensions de méthodes sont utilisées par Linq dans plusieurs cas...
Ca ne m'avait pas sauté aux yeux de prime abord car ce n'est pas obligatoire de les utiliser, mais dans ce scénario précis, les extensions sont d'une grande élégance...

voila ! et c'est pour ce genre de cas que j'aimerai bien les avoir en java, meme si je suis d'accord, faut surtout pas en buser (comme le import static actuel)

[pierreact]

Ruby le fait tres bien:

Time.new.to_i.to_s

Autrement dit: Obtenir le temps actuel, le convertir en timestamp unix (to_i (to integer)) et le convertir en String...
Ruby a plein de choses dans le genre...

Ceci dit, meme si ca s'adapte tres bien a ruby, je trouve que c'est tres fouillis en java...
Je vote contre

[zais_ethael]

Tiens, j'avais jamais pensé à cette généralisation. Est-ce qu'il y a un design pattern connu qui explicite ça ? (avec un nom qui rocks)

Heu... non, ça existe depuis le C

Pour ma part, j'ai voté contre. Juste pour pouvoir écrire le code autrement (et pas forcément mieux, ça ne fait même pas gagner un seul caractère) plus personne ne saurait quelles sont les méthodes proposées par les classes et quelles sont les méthodes qui ne le sont pas.