Discussion :

[adiGuba]

En fin d'année dernière, le report de Java 7 laissait envisagé l'intégration des closures. Cela a donné naissance au projet Lambda dont l'objectif était de regrouper les différents travaux afin d'en sortir une spécification claire et fonctionnelle quitte à se passer de certain "power-concept".

Il en ressort une proposition d'expressions Lambda relativement allégé vis à vis des multiples et très complètes propositions de closures qui ont pu être proposé par le passé. Mais cela s'accompagne également de nouveaux concepts fort intéressants (Exception Transparency, Method References, Defender Methods).

Voyons voir de quoi il en retourne...




» Lire la suite!

Billet original publié sur les blogs de developpez.com...

[tchize_]

merci pour ce billet adiguba, c'est toujours un plaisir à lire.

Je craint avec ces nouvelle facilité qu'on commence à retrouver du code moche à la pelle, encore plus qu'actuellement. On v voir des programmeur utiliser les defendeur methode pour faire du veritable héritage multiple, avec des interface donc aucune méthode ne devra être implémentée . Un peux comme des abstract, sauf qu'on pourrait "hériter" de plusieurs.


Aussi, comme les defenders methods seront "injectées" dans les classes implémentant de manière incomplète l'interface, comme le securtiymanager va empecher ces defenders methods de tripatouiller l'objet en question si l'accès à celui-ci est supposé restreint pour des raisons X ou Y.


Enfin, une question sur ce bout de code

Code :

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

Comparator<String> compare = String#compareToIgnoreCase(String);

Le Comparator prend deux paramètre, je ne vois qu'un seul paramètre dans la référence (le deuxième String). Je suppose que le premier paramètre du Comparator est utilisé comme instance sur laquelle la méthode doit être appelée. Comme les distinguer? Suis-je obligé de faire

Code :

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

Comparator<String> compare = #(a, b){a.compareToIgnoreCase(b)}

oui y a-t-il un moyen plus direct, du genre

Code :

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

Comparator<String> compare = a#(a, b)compareToIgnoreCase(b){

La différence étant que dans le premier cas, je crée une méthode anonyme, dans le deuxième cas, j'utilise directement la référence à une méthode existante....

Enfin, aussi, avec les Methode référence utilisant une isntance, comment le cas du null sera-t-il traité? Exception? Si oui, l'implémentation d'un comparator en passant directement une référence sera plus sujette à erreur....


Et last but not least. On a une date de sortie? Parce que sur le site de java.net ils parlent d'une sortie pour 2008 qui a été repoussée en janvier 2009? Faudra leur offrir un calendrier

[adiGuba]

Je craint avec ces nouvelle facilité qu'on commence à retrouver du code moche à la pelle, encore plus qu'actuellement. On v voir des programmeur utiliser les defendeur methode pour faire du veritable héritage multiple, avec des interface donc aucune méthode ne devra être implémentée . Un peux comme des abstract, sauf qu'on pourrait "hériter" de plusieurs.

Quel que soit la fonctionnalité, il y a toujours des solutions pour faire un truc sale

Aussi, comme les defenders methods seront "injectées" dans les classes implémentant de manière incomplète l'interface, comme le securtiymanager va empecher ces defenders methods de tripatouiller l'objet en question si l'accès à celui-ci est supposé restreint pour des raisons X ou Y.

Les méthodes d'extension reste des méthodes static classique, avec les mêmes restrictions. Le code injecté devrait se contenter d'appeler la méthode static. Par exemple pour un éventuelle sort() dans List cela générerait une méthode comme ceci :

Code :

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

1
2
3
public void sort() {
     Collections.sort(this);
}

Il n'y a aucun tripatouillage

Enfin, une question sur ce bout de code

Code :

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

Comparator<String> compare = String#compareToIgnoreCase(String);

Le Comparator prend deux paramètre, je ne vois qu'un seul paramètre dans la référence (le deuxième String).

Il s'agit ici d'une référence sur une méthode d'instance, donc l'instance est rajouté en premier paramètre ce qui génère une méthode avec deux paramètre...

Je suppose que le premier paramètre du Comparator est utilisé comme instance sur laquelle la méthode doit être appelée. Comme les distinguer? Suis-je obligé de faire

Code :

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

Comparator<String> compare = #(a, b){a.compareToIgnoreCase(b)}

oui y a-t-il un moyen plus direct, du genre

Code :

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

Comparator<String> compare = a#(a, b)compareToIgnoreCase(b){

La différence étant que dans le premier cas, je crée une méthode anonyme, dans le deuxième cas, j'utilise directement la référence à une méthode existante....

Attention car là tu mélanges "Expressions Lambda" et "Method References" !

Pour les "Method Reférences" sur une méthode d'instance tu as deux possibilités :

• Soit tu références une méthode de manière static, et dans ce cas un paramètre initial est automatiquement rajouté à la signature :
  

  Code :

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

  String#compareToIgnoreCase(String); // signature : int(String,String)

• Soit tu références la méthode via une instance, et là tu appeleras automatiquement la méthode sur l'instance indiqué (pas d'ajout de paramètre) :
  

  Code :

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

  1
  2
  String text = "hello";
  text#compareToIgnoreCase(String); // signature : int(String)

[quote=tchize_;5431577]Enfin, aussi, avec les Methode référence utilisant une isntance, comment le cas du null sera-t-il traité? Exception?
Un NPE me semble tout indiqué oui...

Si oui, l'implémentation d'un comparator en passant directement une référence sera plus sujette à erreur....

Je ne pense pas que les Comparator gèrent les valeurs nulles... mais oui les valeurs nulle devront être géré si on les utilisent (comme toujours en fait).

Et last but not least. On a une date de sortie? Parce que sur le site de java.net ils parlent d'une sortie pour 2008 qui a été repoussée en janvier 2009? Faudra leur offrir un calendrier

Alors là aucune idée !
Les derniers plannings prévoyait une version finale pour septembre mais je doute que ce soit le cas. Le build "feature complete" aurait dû sortir en mai... mais on n'y est pas encore.

Je pense qu'il faudra attendre JavaOne pour avoir plus de news là dessus.


a++