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
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
Comparator<String> compare = #(a, b){a.compareToIgnoreCase(b)}
oui y a-t-il un moyen plus direct, du genre
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
Partager