adiGuba:Blog

Un article de adiGuba    7 Commentaires

Les Closures style BGGA sont extrêmement complète, mais apporte également leurs lots de complexité. De ce point de vue là, la proposition CICE prend le problème à contre pied et propose une implémentation la plus simple possible.

D’ailleurs la documentation donne le ton dès le début, en titrant « Closures without Complexity« …

Sommaire / Accès rapide :

• Closures ?
• Accès aux variables locales
• Structures de contrôles
• Conclusion

Closures ?

Oubliez les « functions types« , « method references » ou autres « structures de contrôle » de BGGA. CICE se veut plus simplet et le terme même de « closure » est lui-même peu utilisé dans la proposition.

En fait cela consiste simplement à proposer une syntaxe simplifiée pour la déclaration des classes anonymes, qui peut être utilisé pour :

• Implémenter les interfaces mono-méthode (tout comme BGGA, les méthodes existantes dans Object ne sont pas prise en compte).
• Étendre les classes-abstraites « mono-méthode-abstraite », c’est à dire ne possédant qu’une seule et unique méthode abstraite.

Ainsi, si on prend comme exemple le code suivant, permettant de trier une liste de chaînes :

List<String> list = ... 

 

Collections.sort(list, new Comparator<String>() { 

  public int compare(String s1, String s2) { 

    return s1.compareToIgnoreCase(s2); 

  } 

});

La version CICE se contente d’alléger l’écriture en supprimant les informations rébarbatives, ce qui nous donne :

Collections.sort(list, Comparator<String>(String s1, String s2) { 

  return s1.compareToIgnoreCase(s2); 

});

Le principe consiste à omettre le mot-clé new (afin de bien différencier cette syntaxe de celle de création standard de classe anonyme), et de limiter les informations au stricte minimum : le nom de la classe/interface (et son éventuel paramétrage générique), ainsi que la liste des paramètres de la méthode à implémenter (qui est directement placée après le nom de la classe).

On supprime donc principalement une partie de la déclaration de la méthode, puisque selon le principe de la « mono-méthode » le compilateur peut facilement retrouver ces informations et vérifier leurs cohérence (c’est à dire que le retour du bloc correspondent bien au retour de la méthode).

Bref, il s’agit plutôt de sucre syntaxique permettant d’alléger la déclaration de classe anonymes, et de ce fait elle est parfaitement compatible avec les API existantes sans avoir besoin de conversions spécifiques (ici une closure est une classe anonyme comme une autre sans aucune spécificité).

Accès aux variables locales

CICE propose également une solution pour simplifier l’accès aux variables locales depuis une classe anonyme, afin de passer outre les limitations dû à l’utilisation de final, ceci via deux propositions :

• Le mot-clé final devient implicite pour toute variable locale qui est initialisée ou assignée exactement une fois, ainsi que pour tout paramètre qui n’est pas réassigné dans le corps de la méthode. En clair toute variable qui respecte les conditions d’une variable final le deviendrait implicitement. De ce fait, ces variables deviennent directement utilisables depuis les classes anonymes sans avoir à utiliser le mot-clé final. Encore une fois cela ne change pas grand chose : c’est tout simplement le compilateur qui se chargerait de rajouter ce mot-clé, et on conserve donc les mêmes limitations qu’avec le mot-clé final (impossibilité de réassigner la variable).
• Enfin, de la même manière que BGGA avec son annotation @Shared, CICE propose la possibilité d’accéder directement à la variable locale (qui serait alors conservé dans le « heap »), et donc de lui assigner une autre valeur.

  Ici, plutôt qu’une annotation, on utiliserait le mot-clé public pour indiquer que la variable est complètement accessible par toutes les classes anonymes, par exemple :

  
  public int numCompares = 0; 
  
  Collections.sort(list, Comparator<String>(String s1, String s2) { 
  
    numCompares++; 
  
    return s1.compareToIgnoreCase(s2);  
  
  }); 
  
  System.out.println("Nombre de comparaison : " + numCompares);
  
  

Structures de contrôles

Contrairement à BGGA, CICE ne met pas en place de mécanisme de structures de contrôles. Par contre on l’associe avec la proposition ARM qui définit deux nouvelles structures du langage

La première instruction (do(...) {}) a pour objectif de faciliter la gestion des ressources (qui ne peuvent être géré par le garbage collector). Elle permet donc de déclarer un bloc qui s’occupera automatiquement de libérer proprement les ressources :

do (BufferedInputStream bis = ...) { 

  ... // Code utilisant "bis" 

}

Ce qui serait équivalent à :

BufferedInputStream bis = ...; 

try { 

  ... // Code utilisant "bis" 

} finally { 

  bis.close(); 

}

Tout en permettant l’utilisation conjointe de multiples ressources :

do (BufferedInputStream bis = ...; BufferedOutputStream bos = ...) { 

  ... // Code utilisant "bis" et "bos" 

}

La seconde instruction (protected(...) {}) propose une syntaxe permettant d’utiliser les lock de l’API java.ultil.concurrent d’une manière similaire au lock standard avec le mot-clef syncronized :

Lock lock = ...; 

protected (lock) { 

  ... // Code synchronisé avec le "lock" 

}

Conclusion

« Closures without Complexity » : tel est le slogan de CICE. Mais en enlevant toutes la complexité des closures, on se retrouve bien loin des possibilités offertes par les autres propositions. Et s’il y a de bonne idée (j’apprécie particulièrement l’utilisation du mot-clé public pour rendre accessible une variable aux classes anonymes, en lieu et place de l’annotation @Shared de BGGA), l’intégration de CICE ne changerait pas vraiment le développement en Java, et serait en fait plutôt anecdotique : on est bien loin des possibilités offertes par les autres propositions…

Sur le même thème : Où va Java ? Les Closures

• Les Closures style BGGA
• Les Closures style FCM