Discussion :

[tomlev]

Bonjour,

Cette discussion est destinée à recueillir vos commentaires sur l'article La beauté des fermetures (traduction de l'article The Beauty of Closures de Jon Skeet).

Un de ces jours, j’aimerais écrire sur mon blog à propos des diverses propositions pour les fermetures en Java 7. Cependant, quand j’ai commencé à écrire ce billet, j’ai réalisé qu’il était difficile de commencer sans une introduction aux fermetures. Au fil du temps, cette introduction est devenue tellement longue que j’ai eu peur de perdre la plupart de mes lecteurs avant d’arriver à la partie concernant Java 7. Puisque le chapitre 5 du livre (C# in Depth, NdT) traite essentiellement des méthodes anonymes et de comment elles apportent les fermetures à C#, il m’a semblé approprié d’écrire cet article ici (sur le site csharpindepth.com, NdT).

La plupart des articles concernant les fermetures sont écrits en termes de langages fonctionnels, car ceux-ci tendent à mieux les supporter. Cependant, c’est aussi précisément pourquoi il est utile d’écrire un article qui traite de comment elles apparaissent dans des langages orientés objet plus traditionnels. Il y a des chances que si vous programmez dans un langage fonctionnel, vous les connaissez déjà. Cet article traitera de C# (1, 2 et 3) et de Java (avant la version 7).

[tralloc]

Bonjour,
Il aurait été pertinent de décliner les exemples avec Java 8 puisque les lambda arrivent dans cette version qui est pour mars ou avril.

Sinon bon article, merci.
Bonne journée

[tomlev]

Il aurait été pertinent de décliner les exemples avec Java 8 puisque les lambda arrivent dans cette version qui est pour mars ou avril.

Certes... mais je me suis contenté de traduire, je ne pouvais pas ajouter des choses que l'auteur n'avait pas écrites

L'article a été écrit il y a au moins 2 ans il me semble, donc à l'époque les lambdas de Java 8 n'étaient pas encore finalisées...

[tralloc]

Ok, c'est bien dommage.
Mais si tu as du courage pour le faire, tu peux rajouter quelque chose en disant que c'est un ajout de ta part. Ca se fait, non ?

[tomlev]

Mais si tu as du courage pour le faire, tu peux rajouter quelque chose en disant que c'est un ajout de ta part. Ca se fait, non ?

Oui je suppose que ça pourrait se faire, en tant que "note du traducteur"... mais d'un autre côté, je ne connais pas très bien Java, donc je risque de dire des bêtises

[Sebajuste]

Dans le point 5 " Comparaison des stratégies de capture : puissance contre complexité", l'auteur indique qu'il n'est pas possible en java d'avoir facilement le comportement attendu par défaut en C#, à savoir, d'effectuer plusieurs fois l'action sur une même variable (et non sa valeur).

Dans le cas présenté, afficher 10 fois la valeur final du compteur: "10".

Le comportement similaire en java est certes un peux plus complexe, mais il est farfelu de proposer une solution basé sur des tableau pour capturer les références...

Le constat est simple: en java, la référence doit être "final". La solution, et donc de simplement créer un objet "final" qui va encapsuler l'objet à manipuler.

Pour un compteur, AtomicInteger remplis ce rôle (même s'il n'est pas du tout prévu pour ça à la base).

Le code est donc le suivant, et fonctionne comme le cas initial présenté en C#:

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
// Construire d’abord une liste d’actions
List<Runnable> actions = new ArrayList<Runnable>();
 
for (final AtomicInteger counter = new AtomicInteger(0); counter.get() < 10; counter.getAndIncrement()) {
 
     actions.add(new Runnable() {
          public void run() {
               System.out.println(counter.get());
          }
     });
}
 
// Puis les exécuter
for (Runnable action : actions) {
     action.run();
}

[thierryler]

Un détail : les accolades ouvrantes dans les blocs de code en Java sont placées à la ligne suivante et non à la fin de la ligne.

[tomlev]

Le constat est simple: en java, la référence doit être "final". La solution, et donc de simplement créer un objet "final" qui va encapsuler l'objet à manipuler.

Je pense qu'il suggérait un tableau pour éviter d'avoir à créer une classe spécifique pour ça. Dans le cas d'un entier, tu peux effectivement utiliser AtomicInteger, mais il n'y a pas forcément d'équivalent standard pour d'autres types... Idéalement je suppose qu'il faudrait créer une classe Box<T> qui sert à ça (mais si je me souviens bien, en Java on ne peut pas utiliser les types primitifs comme arguments de type générique, si ?)

[tomlev]

Un détail : les accolades ouvrantes dans les blocs de code en Java sont placées à la ligne suivante et non à la fin de la ligne.

C'est juste... Je me suis fait la remarque en traduisant, mais comme l'auteur l'avait écrit comme ça, j'ai laissé comme c'était.

Pour la petite histoire : Jon Skeet est reconnu comme l'un des meilleurs experts de C#, mais pourtant il travaille... chez Google comme développeur Java !

[thierryler]

OK je n'avais pas vu que c'était une traduction

[Sebajuste]

mais si je me souviens bien, en Java on ne peut pas utiliser les types primitifs comme arguments de type générique, si ?

Effectivement, mais cela n'est plus un problème depuis l'outboxing.

Il suffit de typer la classe Box<> avec la classe wraper adéquate (Integer, Byte, Long, Float, etc...). Le "transtipage" avec le type primitif est transparent.