Discussion :

[tchize_]

Normalement ça devrait être bien plus rapide : le travail sur les nouveautés a venir est bien entamé. Java 7 est juste une sorte de pré-Java 8.

De mémoire, java 8 est prévu pour fin 2012 (dans 1.5 an). Pour le reste, oracle envisage le cycle
java 7: sucre
java 8: gros changements
java 9: sucre
java 10: gros changements

etc. avec des cycles de 1.5 an

[_skip]

A pitié, par les types variant, ca a des tonns de p** d'effets de bord. La syntaxe diamant a pour but d'éviter de ce répéter, pas de créer des types variables.

Désolé de te faire pitié mais sur ce coup t'es pas à jour. Le mot clef var en c# ne désigne en rien un type variable, écrire :

Code :

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

var table = new Hashtable<int, List<Client>>()

est strictement équivalent à

Code :

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

Hashtable<int, List<Client>> table = new Hashtable<int, List<Client>>()

Le type est connu à la compilation et n'a aucune ambigüité. Si tu venais à déclarer.

Code :

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

var liste = null;

Ca ne compilerait pas car l'inférence du type n'est pas possible. Ca n'a absolument rien à voir avec un type "variable", c'est un pur sucre syntaxique et toute la force du typage est préservée sans compromis.

Mais cela permet d'écrire

Code :

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

1
2
 
foreach(var listeClient in table.Values )

Alors qu'en java il ne sera probablement pas possible d'écrire autrement que :

Code :

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

1
2
 
for( List<Client> listeClient : table.values() )

Après on aime ou on aime pas, perso j'apprécie car ça m'évite de devoir faire le boulot à la place du compilateur.

[tchize_]

Désolé de te faire pitié mais sur ce coup t'es pas à jour. Le mot clef var en c# ne désigne en rien un type variable, écrire :

ok merci pour l'info, je suis pas trop c#

Pour le diamant, je sais qu'il y a eu beaucoup de discussion a l'époque pour savoir si il fallait inférer à gauche, à droite, des deux coté, et quand on infère de savoir dans quel règles on applique. Dans tous les cas où on regardais le problème, il y avait des pour et des contres, et comme toujours, il faut finir par prendre une décision.

L'avantage avec le diamant c'est qu'on peut faire des choses du genre

Code :

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

1
2
3
4
5
MonType<Map<String,String>> donnee;
if (condition)
  donnee = new MonSousType<>();
else
  donnee = new MonTypeReadOnly<>();

Le type du stockage n'est pas 100% contraint par le type de la déclaration.

[Alex-L]

En 1 mot : Super !

[Uther]

Mais cela permet d'écrire

Code :

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

1
2
 
foreach(var listeClient in table.Values )

C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.

[davcha]

C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.

Le type, c'est IEnumerable<T>. Dans le contexte d'un foreach, c'est vraiment tout ce qui est utile de savoir.

[ratomms]

J'adore ces nouveautés. Et surtout le syntaxe "diamond". Mais je me demande si la dernière version d'Eclipse reconnait ce syntaxe.

[ymajoros]

J'adore ces nouveautés. Et surtout le syntaxe "diamond". Mais je me demande si la dernière version d'Eclipse reconnait ce syntaxe.

En tout cas, Netbeans la reconnaît :-)

[Uther]

En effet Netbean 7 et Eclipse 3.7 gèrent déjà les nouvelles syntaxes de Java 7.

[_skip]

C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.

C'est une question d'habitude je pense... Et de préférence. Perso je me contente d'une variable bien nommée dans ce genre de cas pour deviner le type, sachant que le compilateur est là pour me dire si je me trompe.

Des goûts et des couleurs quoi... Pourtant autant parfois dans des langages comme scala je trouve que le désir d'être concis va parfois trop loin, autant là ça ne m'aurait pas dérangé d'épargner quelques frappes.

Enfin plus directement, j'espère que pour java 8 nous aurons une chance de voir émerger un sucre syntaxique pour les propriétés. Les spec javabeans nous obligeant à créer des pairs get/set plutot que de laisser public les membres, ça ferait sens d'alléger nos Pojo et dto.

[tchize_]

ce qui m'ennuie quand on ne précise pas le type, c'est que si demain la méthode retourne un sous type avec des méthodes supplémentaire (genre machin(String) en plus de machin(Object), le code va changer de sens, alors que si on avait sagement visé le type connu au moment de la création du code (exemple une interface X) machin(String) n'entrerais jamais dans l'équation.

Bref c'est un des nombreux effets de bord qui ont du être pirs en compte dans la décision je suppose

Sans compter qu'un typeage automatique, ca va au delà de facilité l'utilisation des generic

[Népomucène]

Underscores in numeric literals

ça fait franchement bizarre d'écrire un nombre de cette façon

Java recommande d'utiliser les majuscules pour démarquer les mots

Certe, cher Uther, mais je trouve cet argument un peu spécieux.
Car Java nous a habitué à lire des constantes avec autant d'"underscores" qu'un curé peut en bénir :

Code :

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

JOptionPane.INITIAL_SELECTION_VALUE_PROPERTY

Mais bon, on n'est pas obligé de s'en servir. C'est plus rigolo qu'autre chose.

Strings in switch

Enfin une copie de fichier simple

Détection de modification de fichiers

[tchize_]

ça fait franchement bizarre d'écrire un nombre de cette façon

Entre nous, tu préfère tomber sur un code où une constante est écrite

100_000_000
ou
100000000

moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.

[ManusDei]

Entre nous, tu préfère tomber sur un code où une constante est écrite

100_000_000
ou
100000000

moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.

Personnellement j'aurais préféré 100 000 000, mais c'est vraiment du pinaillage.

[Paul TOTH]

Entre nous, tu préfère tomber sur un code où une constante est écrite

100_000_000
ou
100000000

moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.

100*1000*1000;

ou encore

MILLE = 1000;
MILLIONS = MILLE * MILLE;
JACKPOT = 185 * MILLIONS;

[_skip]

ce qui m'ennuie quand on ne précise pas le type, c'est que si demain la méthode retourne un sous type avec des méthodes supplémentaire (genre machin(String) en plus de machin(Object), le code va changer de sens, alors que si on avait sagement visé le type connu au moment de la création du code (exemple une interface X) machin(String) n'entrerais jamais dans l'équation.

En même temps, de mon point de vue ton exemple d'introduction d'un overload incompatible dont le type en paramètre est une sous-classe d'un autre type pour lequel il existe déjà un overload est un "code smell" qui peut tout à fait flinguer un code style :

x.machin( y.chose() )

Bref pour moi c'est une erreur de programmation qui n'est pas directement liée à l'inférence de type. Enfin j'arrête là parce que ça devient HS.

[Népomucène]

Entre nous, tu préfère tomber sur un code où une constante est écrite

100_000_000
ou
100000000

moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.

Oui, certes, j'ai bien saisi que la lecture en est grandement facilitée.

Mon étonnement vient qu'après des années et des années d'informatique de gestion,
j'ai très rarement écrit une constante en dur dans un programme (ou alors dans les tests).
La dernière, je crois, c'était 6.55957 lors du passage à l'€uro !

Dès lors je me demande pourquoi consacrer de l'énergie pour une question de présentation qui n'arrive que rarement.
Mais peut-être que mes chers confrères vont me trouver quelques cas d'utilisation intensive des constantes

[tchize_]

toutes les constantes ne sont pas bonnes a exporter. Si tu demande à ce que l'affichage se fasse en millions d'euros, par exemple, tu va surement faire un truc du genre

Code :

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

int arrondi = Math.round(montant/1_000_000);

[Uther]

Certe, cher Uther, mais je trouve cet argument un peu spécieux.
Car Java nous a habitué à lire des constantes avec autant d'"underscores" qu'un curé peut en bénir

Ca fait aussi partie des recommandation java :
- NomDeClasse pour les classes
- nomDeVariable pour les méthodes,variables, ...
- NOM_DE_CONSTANTE pour les constantes.

Dès lors je me demande pourquoi consacrer de l'énergie pour une question de présentation qui n'arrive que rarement.
Mais peut-être que mes chers confrères vont me trouver quelques cas d'utilisation intensive des constantes

C'est probablement parce que tu fait de la gestion et que tu n'as pas a manipuler souvent de l'hexadécimal ou du binaire.
Pouvoir faire des séparation dans un nombre décimal est juste un léger plus, mais pour la notation binaire, c'est juste indispensable pour rester lisible.

[Népomucène]

En effet ...
Me voilà donc convaincu de l'intérêt de la chose