L’équipe de committers de Ruby annonce RBS, un nouveau langage de signature de type pour Ruby
L’équipe de committers de Ruby annonce RBS, un nouveau langage de signature de type pour Ruby
et les définitions standard des bibliothèques
Dans un billet de blogue en date de la semaine dernière, l’équipe de committers de Ruby a annoncé l’arrivée d’un nouveau langage de signature de type pour Ruby et les définitions standard des bibliothèques, le langage RBS. Il est développé en collaboration avec d’autres acteurs du domaine, comme Square, et devrait être livré en même temps que la prochaine version de Ruby, Ruby 3. RBS a un outil en ligne de commande qui devraient aussi être livré au même moment, ce qui vous permettra de générer des signatures pour votre propre code Ruby.
Selon le dépôt GitHub du projet, RBS (Ruby Signature) est un langage permettant de décrire la structure des programmes Ruby. Vous pouvez noter la définition d'une classe ou d'un module : notamment les méthodes définies dans la classe, les variables d'instance ainsi que leurs types, mais aussi les relations d'héritage/mélange. RBS permet également de déclarer des constantes et des variables globales. RBS s’inscrit dans le cadre des efforts consentis par la communauté de Ruby pour permettre à Ruby 3 de supporter la vérification statique des types.
En somme, RBS agira à la fois comme un langage et une bibliothèque, ce qui permettra aux utilisateurs de Ruby 3 d'écrire des signatures de type pour les programmes Ruby et des signatures de type intégrées pour les bibliothèques standard Ruby. D’après le poste de Soutaro Mastsumoto, committer Ruby central et ingénieur Ruby chez Square, le langage de signature de type standard rendra les définitions de type dans le code Ruby portables entre les vérificateurs de type. Il encouragera de ce fait la communauté à écrire des types pour ses gems et ses applications.
Les signatures sont écrites dans des fichiers .rbs, ce qui est différent du code Ruby. Vous pouvez considérer que les fichiers .rbs sont similaires aux fichiers .d.ts utilisé avec TypeScript ou aux fichiers .h en C/C++/ObjC. Selon Soutaro, l'avantage d'avoir des fichiers différents est qu'il n'est pas nécessaire de changer le code Ruby pour commencer la vérification du type. Vous pouvez opter pour la vérification de type en toute sécurité sans modifier aucune partie de votre flux de travail. En outre, Soutaro identifie deux caractéristiques principales pour RBS.
Premièrement, il s’agit de la prise en charge améliorée du “duck typing”. Le duck typing est un style de programmation populaire chez les Rubyistes. En effet, c’est un style de programmation qui suppose qu'un objet sera en mesure de répondre à un certain ensemble de méthodes. L'avantage du duck typing est la flexibilité. Il ne nécessite pas d'héritage, de mixage ou de déclarations d'implémentation. Si un objet a une méthode spécifique, il fonctionne. Le problème est que cette hypothèse est cachée dans le code, ce qui rend le code difficile à lire d'un seul coup d'œil.
Selon Soutaro, pour s’adapter au duck typing, l’équipe a introduit des types d'interface. Un type d'interface constitue un ensemble de méthodes indépendantes des classes et des modules concrets. Ainsi, si vous voulez définir une méthode qui nécessite un ensemble spécifique de méthodes, vous pouvez l'écrire avec des types d'interface. Soutaro estime que cette façon de faire est mieux que le duck typing traditionnel puisqu’elle définit une interface explicite qu'une classe ou un module est censé implémenter et fournit des conseils pour la documentation et les plugins de l'éditeur.
Cela permet alors d'exposer l'interface autrefois implicite comme une solide documentation actionnable. La seconde caractéristique clé de RBS est la non-uniformité. Il s’agit d’un autre modèle de code qui permet à une expression d'avoir différents types de valeurs. Il est aussi populaire en Ruby. Il est utilisé notamment lorsque vous définissez une variable locale qui stocke des instances de deux classes différentes, lorsque vous écrivez une collection hétérogène ou bien lorsque vous rendez deux types de valeur différents d'une méthode.
Pour s'adapter à cela, RBS prend en charge des types d’union et la surcharge de méthodes. Les types d'union et la surcharge de méthodes sont couramment observés dans le code Ruby et dans les bibliothèques standard. Voici ci-dessous les avantages de l’utilisation de RBS tels que présentés par Soutaro :
- permet de trouver d'autres bogues : il permet de détecter un appel à une méthode non défini, une référence constante non définie, et d'autres choses qu'un langage dynamique aurait pu manquer ;
- dispose de la sécurité nulle : les vérificateurs de types basés sur RBS ont un concept de types optionnels, un type qui permet à la valeur d'être nulle. Les contrôleurs de types peuvent vérifier la possibilité qu'une expression soit nulle et découvrir une méthode indéfinie ;
- a une bonne intégration aux EDI : l'analyse des fichiers RBS permet aux EDI de mieux comprendre le code Ruby, les complétions de noms de méthodes s'exécutent plus rapidement, les rapports d'erreurs à la volée détectent plus les problèmes, etc. ;
- permet un duck typing guidée : les types d'interface peuvent être utilisés pour le duck typing. Cela aide les utilisateurs de l'API à comprendre ce qu'ils peuvent faire avec plus de précision. C'est une version plus sûre du duck typing.
Source : Soutaro Matsumoto, Référentiel GitHub de RBS
Et vous ?
Qu'en pensez-vous ?
Voir aussi
Répondre avec citation
Envoyé par amosdesable
Partager