TypeScript 2.0 est disponible en version bêta
Et apporte la signature d'index implicites ainsi que le support des définitions de modules UMD

Le , par yahiko

0PARTAGES

7  0 
TypeScript 2.0 disponible en bêta


La version 2.0 de TypeScript vient d'être publiée en bêta il y a une semaine et est disponible pour Visual Studio ou en mode standalone via NPM en lançant la ligne de commande suivante :
npm install -g typescript@beta

Elle apporte son lot de nouveautés. Même si à première vue, cela peut ne pas être flagrant, l'une de ces nouveautés constitue un tournant majeur dans l'évolution du langage. Il s'agit des types non nulliffiables (non-nullable types).

Types non nullifiables

Les variables null ou undefined sont deux des principales sources de bogues en JavaScript et obligent le développeur à une programmation défensive fastidieuse, diminuant la lisibilité du code. D'autant que ce n'est pas non plus une garantie absolue, dans la mesure où un oubli reste toujours possible. Le concept des types non nullifiables en TypeScript a pour objectif de répondre à ce besoin.

Avant TypeScript 2.0, null et undefined étaient implicitement inclus dans chaque type, y compris ceux définis par le développeur. Ce qui signifiait que si vous aviez une fonction qui prenait une chaîne de caractères en argument, vous ne pouviez pas être sûr à partir du type si vous aviez réellement une chaîne --- vous pouviez avoir null à la place. Cela nécessitait par conséquent l'usage de la programmation défensive comme en JavaScript traditionnel.

Avec TypeScript 2.0, l'option du compilateur --strictNullChecks change ce principe. Le type string est uniquement une chaîne de caractères et le type number est uniquement un nombre, rien d'autre.

Code : Sélectionner tout
let foo: string = null; // Erreur !!
Si vous souhaitez une variable nullifiable, il faudra l'expliciter à l'aide d'une union de types.

Code : Sélectionner tout
let foo: string | null = null; // Correct
Cette option --strictNullChecks génère une erreur si on essaie de rendre null ou undefined une variable non nullifiable, mais génère également une erreur à la compilation, et non durant l'exécution, si on tente par exemple d'accéder à une propriété d'un objet nullifiable.

Code : Sélectionner tout
1
2
3
declare let str: string | undefined; // variable instanciée ailleurs

let upperCased = str.toUpperCase(); // Erreur ! La variable 'str' peut être indéfinie.
Pour une variable initialement déclarée comme nullifiable, comme dans l'exemple ci-dessus, le langage offre la possibilité de préciser ponctuellement qu'à un instant donné il est garanti qu'elle n'est pas null ou undefined afin de ne pas générer d'erreur via l'option --strictNullChecks. Cela se fait avec l'opérateur postfixe !.

Code : Sélectionner tout
let upperCased = str!.toUpperCase(); // Correct. La variable 'str' est postfixée par l'opérateur !.
Cette nouvelle signification pour l'opérateur ! est syntaxiquement valide sans préciser l'option --strictNullChecks, même si en l'absence de ce dernier, il n'a aucun effet.

Les types non nullifiables sont un changement important dans l'histoire encore jeune de TypeScript dans la mesure où c'est, en exagérant un peu, deux langages qui vont devoir cohabiter : d'un côté, la sémantique des types nullifiables comme c'était le cas jusqu'à présent, et de l'autre, la sémantique des types non nullifiables avec --strictNullChecks. Ces deux sémantiques ne sont pas vraiment compatibles entre elles. Autrement dit, une application devra être pensée en totalité (y compris les modules externes) avec cette logique des types non nullifiables pour avoir une chance de compiler correctement ce qui risque de limiter le succès de cette approche dans un premier temps. Certains préféreront la « souplesse » actuelle où on ne sait pas trop si un objet est null ou pas. Cependant, d'un point de vue de la fiabilité, il serait préférable que cette sémantique plus restrictive des types non nullifiables devienne une bonne pratique à l'avenir. Ceci est d'ailleurs plus conforme à l'esprit global de TypeScript et aura sans doute comme vertu de corriger du code existant, TypeScript, voire JavaScript.

Analyse du flux de contrôle pour les types

La gestion des types non nullifiables a été rendue possible grâce au suivi du typage tout au long du déroulement d'un programme. Dans la version 2.0, des améliorations dans l'inférence de type à tel ou tel endroit précis du code ont été réalisées au cours de l'analyse du flux de contrôle.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
 * @param recipients  Un tableau de destinataires, ou une liste séparée par des virgules de destinataires.
 * @param body        Contenu brut du message.
 */
function sendMessage(recipients: string | string[], body: string) {
    if (typeof recipients === "string") {
        recipients = recipients.split(",");
    }

    // TypeScript sait que 'recipients' est ici un 'string[]'.

    recipients = recipients.filter(isValidAddress);
    for (let r of recipients) {
        // ...
    }
}
À noter qu'après l'affectation à l'intérieur du bloc if, TypeScript comprend qu'il a affaire à un tableau de chaînes de caractères. Ceci peut permettre de détecter des erreurs tôt dans le processus de développement et gagner du temps sur le débogage.

Code : Sélectionner tout
1
2
3
4
5
6
let bestItem: Item;
for (let item of items) {
    if (item.id === 42) bestItem = item;
}

let itemName = bestItem.name; // Erreur ! 'bestItem' peut ne pas avoir été initialisé si 'items' est vide.

Déclarations de modules simplifiées

Un des reproches qui pouvait être adressé à TypeScript concernait la déclaration fastidieuse des modules écrits en JavaScript.

Code : Sélectionner tout
1
2
3
4
declare module "foo" {
    var x: any;
    export = x;
}
Dans le cas où on ne connait pas encore bien un module, ce qui est souvent le cas lors de la première utilisation, il est désormais possible de court-circuiter les déclarations de variables en type any pour simplement écrire ceci en TypeScript 2.0 :

Code : Sélectionner tout
1
2
declare module "foo";
declare module "bar";
Il sera toujours possible de revenir dessus ultérieurement pour affiner ces déclarations avec des types plus précis.

Dans le cas où vous devez importer beaucoup de modules, il est aussi possible d'utiliser des caractères génériques dans les déclarations :

Code : Sélectionner tout
declare module "foo/*";
Tous les modules dans le répertoire foo seront importés par TypeScript.

En vrac

Il serait trop long de présenter en détail toutes les autres nouveautés de TypeScript. Mentionnons donc simplement :

  • union de types discriminée et garde de types basée sur une propriété d'un objet ;
  • spécification du type du paramètre this pour les fonctions ;
  • propriété d'un objet en lecture seule ;
  • spécification de différents répertoires dans la résolution de module ;
  • signatures d'index implicites ;
  • constructeurs privés (private) et protégés (protected) ;
  • propriétés abstraites (abstract) ;
  • propriétés optionnelles dans les classes ;
  • nouveau type never ;
  • option du compilateur --skipLibCheck ;
  • répertoire de sortie des déclarations avec l'option --declarationDir ;
  • support des noms de fichiers génériques (glob) dans tsconfig.json ;
  • amélioration de la modularité de lib.d.ts et support de la nouvelle option --lib ;
  • support des définitions de modules UMD ;
  • virgule finale dans la liste des paramètres d'une fonction ;
  • étiquette jsdoc @typedef pour les fichiers JS ;
  • autocomplétion pour les chaînes littérales ;
  • support de l'extension .js dans les noms de modules à l'import ;
  • compatibilité mutuelle entre --target:es5 et --module:es6 ;
  • marquage des déclarations inutilisées avec les options --noUnusedLocals et --noUnusedParameters


À noter que le support des fonctionnalités asynchrones (async / await) pour ES3 et ES5 n'est toujours pas opérationnel avec cette version 2.0, alors que cela avait déjà été annoncé pour la version 1.8. L'équipe TypeScript l'a reporté pour la prochaine version 2.1 du fait des lourds changements apportés dans le module de transformation de l'arbre syntaxique abstrait et des tests intensifs que cela nécessite. Encore un peu de patience donc.

Toujours est-il que le support de ES6 dans TypeScript atteint à présent 60 % (cf. kangax), à comparer aux 25 % d'il y a un peu plus d'un an et des 74 % de Babel qui semble plafonner.

En conclusion cette nouvelle version est une nouvelle étape majeure dans l'histoire de TypeScript, langage véritablement multiparadigme, tant dans les structures de programmation offertes (classes traditionnelles, prototypes, lambda-fonctions...) que dans le système de typage (statique, dynamique, implicite, explicite, permissif, strict) ce qui reste encore à l'heure actuelle une force et une originalité dans le paysage des langages de programmation.

source : Blog officiel de l'équipe TypeScript

Quelles sont les fonctionnalités qui vous intéressent le plus ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de frfancha
Membre éclairé https://www.developpez.com
Le 17/07/2016 à 12:04
Si une variable est sensée contenir "abc", qu'elle soit nulle ou qu'elle contienne la chaîne vide "" parce que le type est "string not null", dans les deux cas c'est de toute façon incorrect.
Donc cacher la valeur nulle avec la valeur vide me semble plus cacher l'erreur que l'éviter.
0  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 17/07/2016 à 14:35
Citation Envoyé par frfancha Voir le message
Si une variable est sensée contenir "abc",
Alors c'est une constante et pas une variable.
si c'est une variable de type Stirng alors elle doit pouvoir contenir n'importe quelle chaine comme valeur.
Citation Envoyé par frfancha Voir le message
qu'elle soit nulle ou qu'elle contienne la chaîne vide "" parce que le type est "string not null", dans les deux cas c'est de toute façon incorrect.
Donc cacher la valeur nulle avec la valeur vide me semble plus cacher l'erreur que l'éviter.
Non une chaine vide est une valeur comme une autre alors que null n'est pas une valeur. C'est le B.A.BA. du typage null n'est jamais une valeur.
null le symbole existe mais n'a pas de valeur
undefined le symbole n'existe pas.

Si quelques implémentations de certains langages ne font pas la différence entre null et chaine vide ce n'est souvent qu'une question d'implémentation.
la grosse majorité des langages font la différence. dans les systèmes typés statiquement le compilateur peut (ne le fait pas toujours mais il en a les moyen) vérifier la nullité d'un symbole. il est donc en mesure de générer une production (erreur, code, etc.)

Mais si le compilateur doit s'inquiéter des valeurs alors on entre dans une autre dimension.
on est alors dans le domaine de couverture du type. dans ce cas là il faut que le langage définisse les valeurs acceptables pour que le compilateur traite correctement ces espaces de valeurs.
Par exemple Ada permet de définir un type dérivé de Interger dont l'espace est restreint ]2..30] le compilateur sera donc en mesure de vérifier que les valeurs seront comprise entre 2 exclus et 30 inclus.
dans ce cas là on pourrait dériver String pour créer le type NotEmptyString qui exclus la chaine vide.

à ce jour typescript ne permet pas de controller au niveau du compilateur les espaces de valeurs. la seule chose qui est contrôlable ce sont les valeurs dont l'espace dépends des mots mémoire c'est à dire les numbers.

A+JYT
1  0 
Avatar de blbird
Membre éprouvé https://www.developpez.com
Le 18/07/2016 à 10:30
Citation Envoyé par sekaijin Voir le message
à ce jour typescript ne permet pas de controller au niveau du compilateur les espaces de valeurs. la seule chose qui est contrôlable ce sont les valeurs dont l'espace dépends des mots mémoire c'est à dire les numbers.
En même temps si le langage Javascript ne le permet pas non plus, cela ne risque pas d'arriver avec TypeScript.
0  1 
Avatar de Paleo
Membre confirmé https://www.developpez.com
Le 18/07/2016 à 14:49
Dans les nouveautés importantes, le modifieur "readonly" nous évitera l'abus de getters. Plus un mécanisme embarqué d'acquisition des définitions qui devrait rendre tsd et typings obsolètes (voir aussi ici).

Attendre encore pour async/await, c'est un coup dur.
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 18/07/2016 à 15:31
Citation Envoyé par blbird Voir le message
En même temps si le langage Javascript ne le permet pas non plus, cela ne risque pas d'arriver avec TypeScript.
ben si justement c'est ce que peut apporter un langage ci se compile en javascript
le compilateur analyse la syntaxe du code si la vérification des espaces de valeurs fait partit du langage il peut les vérifier avant de produire le JS qui lui ne vérifie rien.

c'est déjà le cas pour la vérification de type
le compilateur typescript vérifie la cohérence des type et génère des erreur de compilation alors que JS ne vérifie pas et transtype au mieux de ce qu'il peut.

pour la vérification des espaces de valeurs il faut ajouter cette notion au langage typescript qui ne la connait pas (explicitement) il sera alors possible de prendre en charche ctte notion dans le compilateur.

ce n'est pas à l'ordre du jour. enfin pas à ma connaissance.

A+JYT
0  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 18/07/2016 à 15:36
Citation Envoyé par Tarh_ Voir le message
Dans les nouveautés importantes, le modifieur "readonly" nous évitera l'abus de getters. Plus un mécanisme embarqué d'acquisition des définitions qui devrait rendre tsd et typings obsolètes (voir aussi ici).

Attendre encore pour async/await, c'est un coup dur.
pour les getters/setters Eifel a trouvé une solution élégante
lorsque tu écris a = b.c; il exécute a = b.getC() et lorsque tu exécute b.c= a; il exécute B.setC(a); cela fait partit du langage tu passe toujours par le setteur ou le getteur

c'est très facile à implémenter dans le compilateur
A+JYT
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 18/07/2016 à 16:11
Citation Envoyé par sekaijin Voir le message
ce n'est pas à l'ordre du jour. enfin pas à ma connaissance.
Non, ce n'est pas à l'ordre du jour. A part ADA d'ailleurs, peu de langage se sont osés aux sous-typages. Sans doute à cause des complications que cela génère au niveau du compilateur, d'autant qu'il est souvent plus pertinent et général de passer par des fonctions prédicats pour tester si une valeur est un élément d'un sous-type. Le sous-typage avec les contraintes de bornes comme cela est implémenté en ADA est finalement un cas particulier réservé aux nombres.

Sinon, avec ton exemple sur Eiffel, je ne vois pas l'originalité. C'est peu ou prou ce qui se passe avec les getters/setters de JS.
0  0 
Avatar de Paleo
Membre confirmé https://www.developpez.com
Le 18/07/2016 à 17:12
Citation Envoyé par sekaijin Voir le message
pour les getters/setters Eifel a trouvé une solution élégante
lorsque tu écris a = b.c; il exécute a = b.getC() et lorsque tu exécute b.c= a; il exécute B.setC(a); cela fait partit du langage tu passe toujours par le setteur ou le getteur
L'idée de "readonly" est plutôt de remplacer un "inst.getA()" par un "inst.a". C'est un gain de performance. En JavaScript, lorsque nous avons une propriété à exposer publiquement en lecture seule, nous avons le choix entre un getter (lourd à écrire et à exécuter) ou bien la déclaration de la propriété publique mais alors celle-ci est modifiable. Ou bien on peut geler (Object.freeze) tout un objet, mais pas une seule propriété. Cela dit, le modifieur "readonly" se comporte de manière étonnante, on lui pardonne car il est fait de JavaScript, un langage tout à fait étonnant.
0  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 18/07/2016 à 21:22
Citation Envoyé par yahiko Voir le message
Non, ce n'est pas à l'ordre du jour. A part ADA d'ailleurs, peu de langage se sont osés aux sous-typages. Sans doute à cause des complications que cela génère au niveau du compilateur, d'autant qu'il est souvent plus pertinent et général de passer par des fonctions prédicats pour tester si une valeur est un élément d'un sous-type. Le sous-typage avec les contraintes de bornes comme cela est implémenté en ADA est finalement un cas particulier réservé aux nombres.

Sinon, avec ton exemple sur Eiffel, je ne vois pas l'originalité. C'est peu ou prou ce qui se passe avec les getters/setters de JS.
C'est le contraire de javascript
tu écris a = b.c et le compilateur génère le code pour a = b.getC();
de même lorsque tu écris b.c = a le compilateur génère le code pour b.setC(a);

ce que ça à d'original c'est que ainsi il n'y a rien de présumé sur l'implémentation.
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
class B {
  Properties p = new Properties();
  String getC() { return this.p.get("aProp");}
  void setC(value) {this.p.set("aProp", value);}
}

//ici ce sont les getters et setteurs qui sont invoqué et ceux même si la propirétés c n'est pas un membre de la classe.
b =new B();
b.c = "test";

console.log(b.c);
quant au sub typage c'est effectivement un gros morceau.
Je trouve que la programmation par contract est en ce sens une bonne approche. pas de subtypage avec la complexité qui l'accompagne et pas de fonction qui ne sont pas dans l'esprit du la méthode.

la solution une version améliorée de try
une fonction définie un contrat il y a des conditions pour l'appeler. par exemple on ne fais pas x / 0 ça n'a pas de sens donc la fonctions divide à pour pré requis que y ne peut être 0. si le développeur respecte les pré requis alors la fonction garantie un résultat.
une fonction s'écrit donc
Code : Sélectionner tout
1
2
3
4
5
function foo(arg1, arg2) {
require ....//une expression booléenne
...//le corps de la fonction
ensure .... //ici une expression booléenne de la garantie
}
appeler la fonction sans respecter le contrat c'est écrire un code faux. il n'est pas nécessaire de lever une exception le programme est faux.
le compilateur avec l'option debug vas produire du code qui vérifie les require
si l'un d'entre eux n'est pas vérifié coredump. inutile d'aller plus loin le programme est faux.
lors de la compil pour release pas de code généré pour les require

pour les ensure c'est différent car malgré toute la bonne volonté qu'on y mets il se peut que le contrat ne puisse être tenu. par exemple lorsque ça dépends d'une ressource externe. le code généré lève une exception en cas de ensure invalide.
avec le try on peut alors ajouter la notion de retry. pour obtenir un code robuste.

A+JYT
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 18/07/2016 à 22:01
J'ai mal interprété ton message sur les getters et les setters. J'avais l'impression que tu paraphrasais simplement le fonctionnement général du concept et pas que tu insistais sur le fait que Eiffel générait des getters et des setters automatiquement. Mea culpa. Ce qui après réflexion est assez logique vu la philosophie du langage. J'ai de vagues souvenirs de ma lecture sur le bouquin de Bertrand Meyer qui doit moisir dans un de mes placards.

La programmation par contrat m'avait paru intéressante en théorie, mais déjà que je trouve ADA trop rigide, que dire de Eiffel... Certes, c'est beau sur le papier tous ces require et ensure, mais dans la pratique, tu codes peut-être de façon beaucoup plus fiable avec cette méthode, mais aussi de façon beaucoup (beaucoup) plus lente. Si TypeScript s'engageait dans un tel formalisme, sûr que tous les développeurs JavaScript le maudirait jusqu'à la 33e génération. Déjà, rien que de faire accepter le typage c'est le chemin de croix.

Ensuite, ça ne résout pas totalement le problème de la fiabilité intrinsèque puisque comme tu le mentionnes toi-même, à charge au développeur de gérer les exceptions à l'exécution (comme en ADA d'ailleurs avec les sous-types) et non à la compilation.

Pour parvenir à du code 100% fiable à priori, de toute manière, on est obligé de passer par les méthodes formelles (langage B, Z, etc). Et là, c'est du code de niche. Tu ne peux pas te permettre de développer un site web avec ces méthodes vu le niveau (et le prix) requis des développeurs et le temps de développement sans commune mesure.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web