Annoncer qu'il peut y avoir des problèmes dynamique de typage en Ceylon, c'est ne pas connaître le langage (et la micro-plateforme qui vient avec). Comme dit précédemment, "value" n'existe qu'à l'écriture du code et disparaît complètement en "pré-compilation" où l'inférence de type fonctionne selon deux principes :
- Pour une référence (variable, valeur ou propriété), il s'agit du type de l'expression de la première assignation. Attention une expression peut être complexe, ainsi le type de "foobar" dans value foobar = foo then "maChaine" else 123; est "String|Integer".
- Pour les fonctions, il s'agit de l'union des types des expression en retour.
L'inférence de type ne peut être utilsé que dans des éléments non publique (shared) garantissant ainsi qu'à la lecteur cela se limite à des unités de compilation bien maîtrisées.
Quand au refactorting, Ceylon s'en prémunie beaucoup en versionnant obligatoirement tous les modules (bibliothèques, jar, etc.).
"value" existe pour faciliter la relecture en évitant d'avoir une déclaration de type longue de trois km qui casse toute la lisibilité au code. Par ailleurs le système de type (moteur d'inférence inclus) est un véritable calculateur qui se simplifie souvent la tâche. Ainsi déclarer une intersection de deux types sans parents communs est traduit par le type Nothing. Qui sert également de type pour l'ensemble vide !
Commencer à jouer avec les unions, intersections et génériques, je peux vous promettre que "value" n'est pas vide de sens. Tant sémantiquement c'est simple à comprendre mais à écrire ca peut vite dévenir illisible.
Il n'y a certes pas de NPE en Ceylon mais il n'y a pas non plus de ClassCastException !
En ce qui concerne l'overloading, je pense que c'est surtout une question de faciliter d'accès au métamodèle. Par exemple pour accéder à une référence de méthode, il suffit d'utiliser le nom de la fonction sans parenthèse. Et côté utilisation comme indiqué il suffit de faire varier le nom des méthodes (ce qui ajouté plus de sémantique et de lisibilité aux APIs) et pour les constructeurs, les "builder pattern" continueront à s'appliquer mais on peut éventuellement définir des méthodes "statiques" (c-à-d des méthodes déclarées au niveau des packages.
Les propriétés du constructeur étant souvent à utiliser comme propriétés de la classe. Ce que je reproche par contre au niveau de la syntaxe des constructeurs c'est qu'il n'y a pas de blocs bien définis, tout le corps de la méthode sert de bloc au constructeur. C'est une syntaxe trop proche du JavaScript à mon goût.
On le met beaucoup en concurrence avec Java mais la JVM n'est pas son seul terrain de jeu. Il se transpile également en JavaScript !
Pour information, la version 1.1.0 est disponible ! Et beaucoup de nouveautés sont arrivées.
Concernant le côté legacy, c'est que l'équipe (et Gavin King en particullier) ne s'est donné aucune contrainte en termes de rétrocompatibilité. Quit à casser beaucoup de code 1.0 avec la 1.1. Même si de l'avis de Gavin King la mise en production à grande échelle de Ceylon n'aura surement pas lieu avant les versions >1.2
1 |
0 |