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

[vbrabant]

Aujourd'hui :

Code :

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

Demain :

Code :

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 :

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]

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]

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

[Napalm51]

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

[austin P.]

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]

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]

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]

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

[bobuse]

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.

[romaintaz]

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é

[bassim]

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

mais j'attends d'autres avis pour voter

[adiGuba]

Envoyé par OButterlin

Perso, j'ai pas compris, si quelqu'un avait la bonté de m'expliquer...

En fait c'est tout simple. L'objectif étant de simplifier l'écriture de méthode.

Actuellement pour "ajouter" une méthode dans une interface on utilise une méthode static qui utilise une instance en premier paramètre.

Par exemple comme l'interface List ne possède pas de méthode sort(), on utilise la méthode static Collections.sort() :

Code :

Collections.sort(list);

Cette proposition vise à faire comme si cette méthode appartenait à l'interface List, en utilisant l'écriture suivante :

Code :

list.sort();

Mais en réalité cela reviendrait exactement au même que le premier code : bref ce n'est que du sucre syntaxique qui simplifie l'écriture de l'appel d'une méthode static...

Envoyé par romaintaz

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é

Sauf que dans ce cas tu n'est plus sûr de pouvoir utiliser la méthode...
Je préfère quand même utiliser une méthode static plutôt qu'avoir à gérer une exception...

a++

[lunatix]

bon, en clair ajourd'hui :

Code :

import static java.util.Collection.sort

permet d'ecrire dans son code

Code :

sort(list);

pas forcement, tres judicieux, et pourtant, le import static bien utilisé est tres utile ! (je pense a l'api Math par exemple, ou certaines classes utilitaires)

la proposition propose de pouvoir ecrire

Code :

list.sort();

je pense que c'est rarement une bonne idée, mais cela permet quand même de bonnes choses, utilisé judicieusement.

Code :

list.synchronizedList().sort();

serait quand meme beaucoup plus lisible que

Code :

sort( synchronizedList( list ) );

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 :

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

[romaintaz]

Envoyé par adiGuba

Sauf que dans ce cas tu n'est plus sûr de pouvoir utiliser la méthode...
Je préfère quand même utiliser une méthode static plutôt qu'avoir à gérer une exception...

Bien entendu, c'était juste pour plaisanter

Je reste contre cette proposition, je suis d'accord avec bassim.
Et que se passe-t-il dans le cas où l'interface List proposerait alors une méthode sort ? Quelle méthode sort serait appelée alors ?

[bobuse]

Envoyé par adiGuba

Actuellement pour "ajouter" une méthode dans une interface on utilise une méthode static qui utilise une instance en premier paramètre.

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)

[bobuse]

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.

[adiGuba]

Envoyé par bobuse

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

Je pense que tu dois parler de l'API standard...

Mais une telle modification impacterait également un très grand nombre d'APIs externes et de programmes...

Bref une perte de la compatibilité ascendante !

a++

[OButterlin]

Bon, merci adiGuba, j'ai compris l'intérêt, c'est déjà ça !
Mais (je sais, j'suis un boulet ), on est bien d'accord que sort() ne fait pas partie de List, alors (même combiné à la proposition 6) comment on va faire comprendre à la méthode sort() qu'elle s'applique à l'objet qui l'appelle ?
Ca consisterait à avoir une méthode genre "getCaller()" ?
(ceci dit, ça me plairait bien le getCaller())

Bref, il y a encore un truc qui m'échappe...

[adiGuba]

Envoyé par OButterlin

Bref, il y a encore un truc qui m'échappe...

C'est juste du sucre syntaxe :

Grosso modo lorsque le compilateur voit ceci :

Code :

1
2
3
import static java.util.Collections.sort
 
list.sort();

Il le remplace par ce code :

Code :

Collections.sort(list);

Et c'est tout !


Bref on continue à appeler une méthode static, mais on la présente comme une méthode d'instance

a++

[bulbo]

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