JDK 7: Proposition 5 : extensions de méthodes [Débat]

**vbrabant** · 16/12/2007, 20h40

Aujourd'hui :

Code :

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

1
2
3
4
5
 
import java.util.Collections;
 
List<String> list = …;
Collections.sort(list);

Demain :

Code :

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

1
2
3
4
5
import static java.util.Collections.sort;

List<String> list = …;
list.sort();

En combinant cette proposition avec la proposition 6, il serait possible d'écrire du code de ce style :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
import static java.util.Collections.sort;
 
List<String> strings = ...;
 
strings
    .filter(isCountryName) // could be a closure
    .sort()
    .uniq()
    .each(printString); // ditto

**JPDMJC** · 18/12/2007, 23h31

J'avouerai être plutôt pour, histoire de raccourcir encore plus le code, mais cela ne risque t-il pas de mettre en déroute celui qui lit le code ?
Java est sensé être un langage simple - enfin je crois, et permettre de telles choses pourrait aider à s'emmêler royalement les pinceaux.

Ou pas.

**yann2** · 19/12/2007, 01h44

Bonsoir

Je suis contre, avec ce genre de code on ne sait plus ce qui est static et ce qui est objet. Je préfère plutôt l'ajout d'une méthode sort dans l'interface List par exemple.

A part ça, l'import static ça existe déjà et ça peut être pratique si on en abuse pas (perso je ne l'utilise jamais, ça va tellement vite, et c'est tellement plus parlant, d'écrire Collections.sort() ; il y a de meilleurs perfs quand on utilise l'import static ?).

yann

**®om** · 01/02/2008, 01h20

Totalement contre.

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

**adiGuba** · 01/02/2008, 09h16

Envoyé par ®om

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

**natha** · 01/02/2008, 10h22

Envoyé par adiGuba

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

Pour Java 3 alors

**Napalm51** · 19/12/2007, 09h16

Contre pour la complexité de lecture/compréhension qui deviendrait plus difficile.

**austin P.** · 19/12/2007, 10h18

plus que contre

la lecture du code devient compliqué.
on arrive presque aux problématiques d'héritages multiples (méthodes du même nom, etc..).

tout ça pour gagner quelques lettres....

Aucun interêt.

**lunatix** · 19/12/2007, 10h22

hum, pas facile. Autant effectivement, ca complique la lecture du code, ce qui tends a me faire voter non, mais ca permet d'un autre coté d'implementer des domain specific languages plus facilement.

Je vote pour, en me disant que ca serait a utiliser parcimonieusement (comme le import static en fait), car ca peut permettre d'améliorer certaines api.

**adiGuba** · 19/12/2007, 10h43

Je m'abstiens de voter !

Cette proposition n'est pas forcément très clair et cela risque d'apporter des ambigüités... pourtant il serait intéressant d'avoir un moyen de faire évoluer les interfaces sans casser la compatibilité...

Bref oui sur le principe mais pas comme cela (oui je sais je suis chiant

)

Envoyé par yann2

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

Malheureusement il est impossible de modifier une interface sans casser la compatibilité, car toutes les classes implémentant l'interface DEVRONT obligatoirement implémenter cette méthode...

a++

**OButterlin** · 19/12/2007, 11h02

Perso, j'ai pas compris, si quelqu'un avait la bonté de m'expliquer...
(on se sent nul parfois

)

**romaintaz** · 19/12/2007, 11h06

J'ai voté contre, parce que je trouve que ça apporte trop d'ambiguïté, et ça n'améliore pas franchement la lisibilité du code !

Envoyé par adiGuba

Malheureusement il est impossible de modifier une interface sans casser la compatibilité, car toutes les classes implémentant l'interface DEVRONT obligatoirement implémenter cette méthode...

Ou alors, il faudrait proposer une évolution du Java en proposant des méthodes optionelles dans les interfaces. Les classes implémentant cette interface ne seraient alors pas obligées de définir ces méthodes optionnelles, et dans ce cas, elles lanceraient une exception MethodNotImplementedException

Comme ça, a pu problème de compatibilité

**bobuse** · 19/12/2007, 11h52

Envoyé par adiGuba

Malheureusement il est impossible de modifier une interface sans casser la compatibilité, car toutes les classes implémentant l'interface DEVRONT obligatoirement implémenter cette méthode...

Ben c'est pas la mort, non plus. Ça demande un peu de boulot, mais bon ça se fait.

Mais d'un point de vue design, comme tu dis, ça ne serait peut-être pas super clean de déplacer ces méthodes.

**natha** · 20/12/2007, 09h20

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.

**bobuse** · 19/12/2007, 11h04

Je comprends vaguement ce que veux dire lunatix, mais je rejoins les autres pour dire que c'est la porte ouverte à toutes les fenêtres !
Comme le dit yann2, ce serait plus logique d'ajouter des méthodes déléguantes dans les conteneurs.

**bulbo** · 19/12/2007, 13h29

Contre,

Ce sucre syntaxique n'apporte rien au développeur moderne (ie assisté d'un IDE

) mais par contre rend la relecture et maintenance du code plus complexe.

Bulbo

**OButterlin** · 19/12/2007, 13h59

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

**verbose** · 19/12/2007, 15h07

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.

**woodwai** · 20/12/2007, 09h29

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.