Discussion :

[ptitbob]

Bonjour,

Je suis contre, car cela n'apporte rien au niveau de la lisibilité d'un code ainsi construit.

Cordialement

[sakli]

contre , problème de lisibilité ne est pas facile

[mavina]

Salut,

Pourquoi pas ?
Passer d'un type retour void à un type retour autre n'impacte pas à la compatibilité, ce qui n'est pas le cas du contraire...

F.

[sd0273]

j'ai voté contre, ça me semble juste une bidouille syntaxique pour un résultat cosmétique.
Je dis cosmétique car en l'occurence il s'agit de retomber sur quelquechose de visuellement normal car maListe.sort() est tout de même plus naturel que Collections.sort(maListe)

Tout ça pour contourner le problème de méthodes manquantes (à mon avis oubliée dans le cas du sort) dans des classes implémentant une interface qu'on ne peut plus toucher et dont le comportement a du coup été complété dans d'autres classes, Collections dans notre cas d'exemple.

solution radicale : pour le cas des List, déclarer toute l'arborescence List+Collections en deprecated pour garder la compat. et fusionner le tout correctement et on aura enfin maNouvelleListe.sort();

[mavina]

Ce n'est pas un oubli, puisque la classe "outils" Collections est apparue avec le framework collection dans la version 1.2, et elle possède sort(List)...

F.

[Bollagain]

Contre, résolument contre.

Malgré la pertinance des arguments avancés par lunatix, il me semble que le gain possible est faible par rapport aux risques probables.

Je fais sans doute figure de dynosaure, mais ce point rejoints d'ailleurs un des trucs que je n'aime pas dans le langage Java, a savoir
la confusion qu'il est possible de faire etre methode static et non-static.

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Banane {
 
  String attribut = "Banane des Iles" ;
 
  public static Banane createBanane() { 
    return new Banane() ;
  }
 
  public static void main(String [ ] args)
  {
    Banane b = null ;
    b = b.createBanane() ;
    System.out.println(b);
  }
 
  public String toString() { 
    return attribut ;
  }
 
}

[natha]

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur

Euh, je ne comprends pas ce qui te choque... Ta classe Banane est une Factory dans ce principe d'utilisation, c'est normal que ça fonctionne correctement et que ça soit possible de coder comme ça.

[Bollagain]

Euh, je ne comprends pas ce qui te choque... Ta classe Banane est une Factory dans ce principe d'utilisation, c'est normal que ça fonctionne correctement et que ça soit possible de coder comme ça.

En fait, ce qui me choque, c'est qu'on puisse appeler une méthode static qur autre chose qu'une classe et que par conséquent, on puisse appeler une méthode (static) sur un objet null.

Cela étant dit, tu as raison, c'est tout a fait légale...

[natha]

Cela étant dit, tu as raison, c'est tout a fait légale...

Il y a un warning à la compi par défaut je crois ?
Ca suffit à rendre attentif à l'inutilité d'appeler une méthode statique sur une instance.

[Benetl2008]

Bonjour,

Je suis contre, problème de lisibilité.

Cordialement,

[anarchy_for_espa]

c'est mieux

[kisame]

Comme écrit dans la faq, j'associe les import static de tiger à des using namespace du c++ . Moi c'est un truc que j'ai moyennement aimé. Ca a son utilité, mais ça a ses risques. C'est un truc que j'aime pas utiliser. Ca va pas changer avec l'extension de ce principe aux méthodes.
Pas super convaincu de l'importance de ça comparé au risque de confusion. Contre.

C'est vrai que ton main, Bollagain, me choque aussi

[fatypunk]

Ce n'est pas un oubli, puisque la classe "outils" Collections est apparue avec le framework collection dans la version 1.2, et elle possède sort(List)...

F.

Je ne suis certain qu'il s'agisse d'un oubli non plus... Mais qu'importe la raison qui motiverais l'ajout de méthode, la depreciation et nouvelle définition et la seule qui soit propre !

Contre, résolument contre.

Malgré la pertinance des arguments avancés par lunatix, il me semble que le gain possible est faible par rapport aux risques probables.

Je fais sans doute figure de dynosaure, mais ce point rejoints d'ailleurs un des trucs que je n'aime pas dans le langage Java, a savoir
la confusion qu'il est possible de faire etre methode static et non-static.

L'idée même que le code de la méthode main ci dessous fonctionne me fait mal au coeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Banane {
 
  String attribut = "Banane des Iles" ;
 
  public static Banane createBanane() { 
    return new Banane() ;
  }
 
  public static void main(String [ ] args)
  {
    Banane b = null ;
    b = b.createBanane() ;
    System.out.println(b);
  }
 
  public String toString() { 
    return attribut ;
  }
 
}

Ca me choque aussi mais il n'est pas possible de faire plus qu'un warning pour des raisons de compatibilité.

[LeGritche]

L'idée est très bonne, mais ça amène trop de risques de confusions.
=> contre

Par contre avec un autre "opérateur" que ".", je serais déjà plus ouvert.

Genre : list|sort();

[TPReal]

C'est une bonne idee a ajouter des methods comme sort() a List class. Utiliser toujours ce bizarre objet Collections est... bizarre, et ajouter le sort() method ferait les List sur Java plus comme les objects vrais. Il faut que une List peut se sorter, sans acune classe exterieure. Et je suis pour les lambdas (closures) aussi, et ca ferait beaucoup de choses avec Lists plus facile (comme sur C#, LINQ).

Mais ce strings.filter(isCountryName).sort().uniq().each(printString) c'est une idee mouvaise. Java n'est pas Ruby pour faire choses comme ca. Le method sort() peut sorter la List "in situ", ou retourner une List sortee, mais ne pas les deux choses en meme temps, ca n'aurait pas de raison.

[fridobox]

Contre,

Déjà, avec cet import statique, comment sait-on quelle classe obtient cette méthode statique? Rien n'indique que Collections.sort() sera attribué à List.

Pour ce genre de sucre synthaxique, tout le monde n'aime pas donc il suffit de le faire soi-même (si personne d'autre n'y met les doigts).
J'utilise depuis longtemps une classe GBC pour remplacer GridBadConstaints avec une utilisation en cascade :

Code :

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

new GBC(0,1).insets(2,5,2,5).fill(GBC.BOTH);

Effectivement List pourrait avoir une méthode statique sort() (ou plutôt une interface SortableList comme le propose fatypunk) mais cette méthode n'utilise rien de l'interface List. C'est pourquoi à mon avis elle est externalisée dans Collections afin de ne pas surcharger List en méthodes. C'est la même chose pour

Code :

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

Arrays

et aussi

Code :

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

StringUtils

(excellente classe de Apache).