+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 110
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    39

    Par défaut TypeScript 2.0 disponible

    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 ?
    Tutoriels et FAQ TypeScript

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    260
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 260
    Points : 454
    Points
    454

    Par défaut Hum

    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.

  3. #3
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 971
    Points : 8 312
    Points
    8 312

    Par défaut

    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

  4. #4
    Membre éclairé

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    415
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 415
    Points : 830
    Points
    830

    Par défaut

    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.

  5. #5
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 194
    Points : 558
    Points
    558

    Par défaut

    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.

  6. #6
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 971
    Points : 8 312
    Points
    8 312

    Par défaut

    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

  7. #7
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 971
    Points : 8 312
    Points
    8 312

    Par défaut

    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

  8. #8
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 110
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    39

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  9. #9
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 194
    Points : 558
    Points
    558

    Par défaut

    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.

  10. #10
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 971
    Points : 8 312
    Points
    8 312

    Par défaut

    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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

  11. #11
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 110
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    39

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  12. #12
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 110
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    39

    Par défaut

    Pour information, la version beta 2.0 de TypeScript est disponible par défaut dans la quatrième Preview de Visual Studio 2015. Il n'est donc plus nécessaire de télécharger de plugin additionnel.

    A noter de plus que l'Intellisense sur le code JavaScript peut être amélioré grâce à la présence de fichiers de définition de types TypeScript ou à la présence de commentaires au format JSDoc.
    Tout ceci est possible grâce au sous-projet Salsa mené en parallèle par l'équipe TypeScript qui permet de réutiliser des services TypeScript pour le langage JavaScript.
    Tutoriels et FAQ TypeScript

  13. #13
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 110
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 110
    Points : 6 122
    Points
    6 122
    Billets dans le blog
    39

    Par défaut La Release Candidate de TypeScript 2.0 est publiée

    La Release Candidate de TypeScript 2.0 est publiée

    Aujourd'hui vient d'être publiée la Release Candidate de TypeScript 2.0 qui peut être installée en stand alone via NPM : npm install -g typescript@rc.

    Pour que Visual Studio Code prenne en compte cette nouvelle version, vous pouvez suivre la démarche publiée dans le billet suivant : Utiliser Visual Studio Code avec une version de TypeScript plus récente

    Pour Visual Studio 2015 (Update 3 minimum), il convient de télécharger un plugin.
    Tutoriels et FAQ TypeScript

  14. #14
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 971
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 971
    Points : 8 312
    Points
    8 312

    Par défaut

    Hors sujet

    j'ai fais une réponse via Android et lorsque j'ai voulu la corriger le message a été supprimé
    j'ai l'impression que si on réédite son message depuis le smartphone ça le supprime.

    Je reviendrais dessus le sujet lorsque j'aurais un peut de temps.
    A+JYT

  15. #15
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 792
    Points : 60 805
    Points
    60 805

    Par défaut Microsoft a annoncé la disponibilité générale de TypeScript 2.0

    Microsoft a annoncé la disponibilité générale de TypeScript 2.0,
    qui embarque l'analyse du flux de contrôle pour les types

    Après deux ans de développement en interne, Microsoft a présenté TypeScript en octobre 2012 comme étant un langage de programmation libre et open-source développé qui a pour but d'améliorer et de sécuriser la production de code JavaScript. Étant un sur-ensemble de JavaScript, tout code JavaScript correct peut être utilisé avec lui.

    En août 2015, TypeScript affichait 275 000 téléchargements npm (gestionnaire de paquets officiel de Node.js), un nombre qui s’élève désormais à plus de deux millions. DefinitelyTyped, un dépôt GitHub de fichiers de déclarations, contient à présent plus de 2000 bibliothèques écrites par plus de 2500 contributeurs.


    La version 2.0 apporte de nouvelles fonctionnalités qui avaient déjà été présentées dans la phase bêta et RC. Rappelons en quelques une :
    • les types non nullifiables : 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.
    • l’analyse de flux de contrôle pour les types : TypeScript disposait déjà d’une analyse de flux de contrôle depuis la version 1.8. La version 2.0 vient étendre l’analyse à plus de flux de contrôle pour produire les types les plus spécifiques possibles. Combiné aux types non-nullifiables, TypeScript peut effectuer des contrôles plus complexes comme l’analyse d’affectation définitive.

      Code JavaScript : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      function f(condition: boolean) {
          let resultat: number;
          if (condition) {
              resultat = calculDeCertainesChoses();
          }
       
          // Erreur ! 'resultat' pourrait ne pas avoir été initialisé !
          return resultat;
      }
    • la possibilité de définir des propriétés en lecture seule :
      Code JavaScript : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      class Personne {
          readonly nom: string;
       
          constructor(nom: string) {
              if (nom.length < 1) {
                  throw new Error("Nom vide !");
              }
       
              this.nom = nom;
          }
      }
       
      // Erreur ! 'nom' est défini en lecture seule.
      new Personne("Daniel").nom = "Dan";


    « A partir de la même syntaxe et sémantique que des millions de développeurs JavaScript connaissent aujourd'hui, TypeScript permet aux développeurs d'utiliser du code JavaScript existant, intégrer les bibliothèques JavaScript populaires, et appeler du code TypeScript depuis JavaScript. Les types statiques optionnels de TypeScript permettent aux développeurs JavaScript d’utiliser les outils et les pratiques de développement hautement productifs comme la vérification statique et la refactorisation de code lors de l'élaboration d’applications JavaScript » a conclu l’équipe TypeScript qui a tenue à remercier la communauté pour ses retours et ses encouragements. .

    Les utilisateurs peuvent télécharger TypeScript 2.0 pour Visual Studio 2015 (dans ce cas, ils auront besoin de la mise à jour 3), l'obtenir avec NuGet, commencer à l'utiliser dans Visual Studio Code ou l'installer avec npm. Pour ceux qui se servent de la préversion de Visual Studio "15", TypeScript 2.0 sera inclut dans la prochaine mise à jour. TypeScript est entré dans le top 15 des langages les plus populaires selon GitHub d'après un classement qui date de la semaine dernière.

    télécharger TypeScript 2.0

    Source : Microsoft

    Voir aussi :

    TypeScript entre dans le top 15 des langages les plus populaires selon GitHub et figure aux côtés de Swift et de JavaScript
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

Discussions similaires

  1. Réponses: 6
    Dernier message: 15/12/2011, 09h22
  2. Le Qt SDK 1.1 est disponible en beta
    Par LittleWhite dans le forum Qt
    Réponses: 4
    Dernier message: 05/05/2011, 16h12
  3. [AC-2010] Le runtime de Microsoft Access 2010 disponible en Beta
    Par Tofalu dans le forum Runtime
    Réponses: 0
    Dernier message: 28/11/2009, 10h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo