JDK 7: Proposition 5 : extensions de méthodes

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

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.

Contre, allez reprendre un code en vous demandant

Citation:

---

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

F.

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.

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.

Citation:

---

Envoyé par lunatix

De plus ca permetrait de faire plus facilment des api de type DSL (voir mon blog :oops:, 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:

---

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

---

;)

Citation:

---

Envoyé par adiGuba

Je m'abstiens de voter !

---

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

Contre.

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

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

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.

Pour ! au moins pour pouvoir ecrire:

Code:

---

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

Citation:

---

Envoyé par bmoussaud

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 ?

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

Citation:

---

Envoyé par Keihilin

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

---

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

Citation:

---

Envoyé par lunatix

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# :mrgreen:

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.

Citation:

---

Envoyé par 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.

---

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

Code:

---

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:

---

1 2 3

MyList maList = new MyList(); maList.sort();

---

???

Citation:

---

Envoyé par bassim

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.

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

Citation:

---

Envoyé par Keihilin

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)

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

Citation:

---

Envoyé par bobuse

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

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.