IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

TypeScript Discussion :

TypeScript 1.5 en production


Sujet :

TypeScript

  1. #1
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut TypeScript 1.5 en production
    TypeScript 1.5 entre en production

    Ce lundi 20 juillet, l'équipe TypeScript vient d'annoncer la mise en production de la version 1.5 du langage, trois mois après l'annonce de la version alpha. Ce délai de mise en production relativement long par rapport aux précédentes versions montre le saut à la fois qualitatif et quantitatif opéré par cette version 1.5.

    Pour avoir un panorama des nouvelles fonctionnalités, on peut utilement se référer à l'article annonçant la version alpha. Pour rappel, cette version 1.5 ajoute :
    • Une nouvelle syntaxe pour l'importation de modules permettant de choisir plus finement les composants à inclure
    • Les décorateurs, à titre expérimental, développés en collaboration avec Angular, Ember et Aurelia.



    Cette version 1.5 précise en outre certains concepts.

    Espace de nommage
    Les notions assez peu satisfaisantes de "modules internes" et "modules externes" ont été clarifiées.
    Les modules internes qui étaient déclarés à l'aide du mot-clé module peuvent désormais être déclarés à l'aide du nouveau mot-clé namespace dans la mesure où cette notion de module interne dans TypeScript rejoint en grande partie celle d'espace de nommage existant dans d'autres langages (C++ ou C# par exemple).

    Nouveaux formats de modules
    Les modules externes sont quant à eux désormais désignés modules, tout simplement. A noter que TypeScript prend en charge deux nouveaux formats de modules (au sens serveur). En plus de AMD et CommonJS, cette version 1.5 peut générer des modules SystemJS et UMD faisant de TypeScript de plus en plus une boite à outils pour le développement Web et pas uniquement un simple langage.

    Centralisation des dépendances de compilation
    La déclaration des dépendances externes à un fichier source se faisait jusqu'à présent soit à l'aide de l'instruction ///<reference>, relativement laide il faut bien le dire, ou via la ligne de commande lors de l'appel au compilateur. Il est possible désormais de définir un fichier nommé par défaut tsconfig.json contenant toutes les dépendances nécessaires à la compilation d'un projet.

    Prise en charge ES6
    Enfin, cette version de production fait un bond considérable dans sa prise en charge de la norme ES6 passant d'une couverture fonctionnelle de 25% lors de la version alpha, à un taux de 52% avec cette version de production, soit plus du double, rejoignant ainsi le pur transpileur ES6 Traceur.

    Cette version 1.5 est une étape majeure dans l'évolution du langage TypeScript où de nombreux aspects ont été améliorés, tant que le plan de la syntaxe pure que sur le plan de la compilation ou de l'intégration avec d'autres outils ou composants. Des orientations majeures ont été prises comme l'adjonction d'un polyfill pour gérer les décorateurs. Il semblerait que TypeScript se montre plus ambitieux quant à ses objectifs à plus long terme en ne se contentant plus de n'être qu'un langage transpilant vers JavaScript, mais de se positionner comme un point nodal dans le processus de développement Web.

    source : Blog officiel de TypeScript

    Que pensez-vous des nouveautés apportées par cette nouvelle version de TypeScript ?

  2. #2
    Membre éclairé Avatar de alves1993
    Homme Profil pro
    Développeur Java/Dart/Javascript/Android (FullStack)
    Inscrit en
    Décembre 2012
    Messages
    222
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Développeur Java/Dart/Javascript/Android (FullStack)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2012
    Messages : 222
    Points : 659
    Points
    659
    Par défaut
    Que pensez-vous des nouveautés apportées par cette nouvelle version de TypeScript ?
    Assez important .

    Il semblerait que TypeScript se montre plus ambitieux quant à ses objectifs à plus long terme en ne se contentant plus de n'être qu'un langage transpilant vers JavaScript, mais de se positionner comme un point nodal dans le processus de développement Web.
    Vraiment TypeScript !!!! J'imagine le Web dans 5 ans (Dart vs TypeScript vs Javascript vs autre chose) se sera vraiment cool et concurrentiel .

  3. #3
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 066
    Points : 4 233
    Points
    4 233
    Par défaut
    Citation Envoyé par alves1993 Voir le message
    Assez important .



    Vraiment TypeScript !!!! J'imagine le Web dans 5 ans (Dart vs TypeScript vs Javascript vs autre chose) se sera vraiment cool et concurrentiel .
    On aura peut être WebAssembly d'ici là.

  4. #4
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 189
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 189
    Points : 4 768
    Points
    4 768
    Par défaut
    Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.

    Parce que Dart et TypeScript, au final ça sera juste pour compiler du JS ou du WA. Dart n'a jamais fonctionné en dehors de Chrome et c'est mal parti pour que ça change.

  5. #5
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 066
    Points : 4 233
    Points
    4 233
    Par défaut
    Citation Envoyé par Zefling Voir le message
    Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.

    Parce que Dart et TypeScript, au final ça sera juste pour compiler du JS ou du WA. Dart n'a jamais fonctionné en dehors de Chrome et c'est mal parti pour que ça change.
    Surtout que google fait partit des promoteurs de WebAssembly

  6. #6
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Il n'y a pas vraiment d'opposition entre JavaScript et WebAssembly. WebAssembly est une évolution logique (voire inévitable) de asm.js, passant du format texte en format binaire/bytecode, beaucoup plus rapide à interpréter.

    Le fait que WebAssembly puisse se généraliser avec la collaboration des principaux éditeurs de navigateurs est de toute façon une bonne nouvelle pour TypeScript puisque cela enlèvera un argument aux zélotes de JavaScript qui ne supportent pas qu'il y ait une phase de compilation entre le code source et l'exécution dans le navigateur.

    WebAssembly aidera aussi à propager l'idée que le typage des données est une bonne chose (il y a 15 ans, je n'aurai jamais imaginer devoir enfoncer cette porte ouverte tellement ça me paraît une évidence, mais il faut croire que JavaScript a réussi à faire régresser les mentalités sur ce point...)

    Comme personne n'écrira nativement en WebAssembly, il faudra passer par un langage tiers de plus haut niveau. Aujourd'hui le langage C++ est privilégié pour la phase de prototype. Mais il est tout à fait envisageable de voir TypeScript un jour se compiler en WebAssembly, notamment parce qu'il intégre déjà cette notion de typage indispensable à WebAssembly (ou à asm.js d'ailleurs).

  7. #7
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2010
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2010
    Messages : 2 066
    Points : 4 233
    Points
    4 233
    Par défaut
    Le but est de supporter le max de langage possible donc c++/java/c#... et bon si on peut faire directement du c# typescript n'a plus de raison d'être, et de ce que j'en ai compris on pourra communiqué entre JS et WebAssembly dans un premier temps mais à terme la compatibilité pourra être cassé pour que WebAssembly supplante JS.

  8. #8
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2013
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2013
    Messages : 242
    Points : 661
    Points
    661
    Par défaut
    Citation Envoyé par Zefling Voir le message
    Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.
    Citation Envoyé par youtpout978 Voir le message
    si on peut faire directement du c# typescript n'a plus de raison d'être, et de ce que j'en ai compris on pourra communiquer entre JS et WebAssembly dans un premier temps mais à terme la compatibilité pourra être cassé pour que WebAssembly supplante JS.
    JavaScript est concurrent de WebAssembly, comme PHP est concurrent des modules PHP codés en C++.

  9. #9
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par youtpout978 Voir le message
    Le but est de supporter le max de langage possible donc c++/java/c#... et bon si on peut faire directement du c# typescript n'a plus de raison d'être, et de ce que j'en ai compris on pourra communiqué entre JS et WebAssembly dans un premier temps mais à terme la compatibilité pourra être cassé pour que WebAssembly supplante JS.
    N'oublions pas la colossale base de code JS dédiée aux applications Web que TypeScript peut exploiter facilement, et pas C# qui lui ne peut pas s’enorgueillir de quelque chose d'équivalent, même si je n'ai rien contre ce langage autre contraire. Tout ce qui peut faire évoluer les mentalités des développeurs JavaScript est de toute façon une bonne chose. Pour le moment, je trouve que TypeScript est la meilleure porte d'entrée. Si demain c'est le langage X ou Y qui peut tirer le niveau vers le haut, je serais le premier supporteur.

    Quoiqu'il en soit, je vois mal JavaScript disparaître dans les 10 à 20 prochaines années. Les développeurs Web par facilité continueront de toute façon à utiliser ce langage permissif. La loi du moindre effort hélas... Quand JavaScript disparaîtra, je pense qu'on aura eu le temps d'inventer de nouveaux langages entre temps.

    edit : bonne analogie Tarh.

  10. #10
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 189
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 189
    Points : 4 768
    Points
    4 768
    Par défaut
    Citation Envoyé par yahiko Voir le message
    Quoiqu'il en soit, je vois mal JavaScript disparaître dans les 10 à 20 prochaines années. Les développeurs Web par facilité continueront de toute façon à utiliser ce langage permissif. La loi du moindre effort hélas... Quand JavaScript disparaîtra, je pense qu'on aura eu le temps d'inventer de nouveaux langages entre temps.
    Pour gérer le DOM, le JS est parfaitement adapté, et pour ça il y a peu de chance que ça change.

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    Mai 2015
    Messages
    589
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Angola

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : Mai 2015
    Messages : 589
    Points : 0
    Points
    0
    Par défaut
    Pour gérer le DOM, le JS est parfaitement adapté, et pour ça il y a peu de chance que ça change.
    Pour rappel le TypeScript devient du javascript une fois compilé. Le browser ne voit pas (encore) le TypeScript. Donc comparer le Javascript et le TypeScript n'a pas vraiment de sens (A part pour la productivité de développement qui est bien meilleur en TypeScript)

    Ce qui pourrait (et qui fera a mon avis) faire abandonné le Javascript c'est ca :
    http://javascript.developpez.com/act...le-JavaScript/

    Si le browser pourrait interpréter directement du TypeScript ca devrait apparemment augmenter les performances.

  12. #12
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    Mai 2015
    Messages
    589
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Angola

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : Mai 2015
    Messages : 589
    Points : 0
    Points
    0
    Par défaut
    Les développeurs Web par facilité continueront de toute façon à utiliser ce langage permissif. La loi du moindre effort hélas...
    Quand ils auront conscience de tous le temp qu'ils perdent a debugger du JavaScript qui est une vraix passoir ils feront des yeux. Perso c'est TypeScript direct et le moins de logique possible dans les contrôleurs. D’abord dans le Backend ou dans les Directives Angular et si c'est pas possible autrement alors dans le Js/Ts.

    Et depuis je jure beaucoup moins souvent et je suis beaucoup plus productif.

  13. #13
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Citation Envoyé par yahiko Voir le message
    le typage des données est une bonne chose (il y a 15 ans, je n'aurai jamais imaginer devoir enfoncer cette porte ouverte tellement ça me paraît une évidence, mais il faut croire que JavaScript a réussi à faire régresser les mentalités sur ce point...)
    JavaScript est typé, tous les langages fournissent des types de base. Il n'y a pas de débat sur le typage en soi mais sur le typage tel que l'apporte TypeScript, c'est-à-dire un typage statique explicite. Le typage dynamique a des cas d'utilisations légitimes, d'où le type Any en TypeScript. Le duck-typing peut également s'avérer très utile, par exemple pour parser des structures d'objets composés à partir d'une description sérialisée comme un JSON. Il n'y a donc pas de solution unique et parfaite, chacun des choix de typage a ses avantages et ses inconvénients. Le mieux est encore d'avoir le choix, et TypeScript est assez souple là-dessus.

    Il n'y a pas de régression de mentalités, juste des adeptes qui considèrent leurs choix techniques comme unique vérité: "le typage dynamique c'est une idée à la con", "le typage statique ça sert à rien" etc... . Et c'est valable pour pleins d'autres sujets en informatique, les paradigmes de programmation, les conventions de code...

  14. #14
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    JavaScript est typé, tous les langages fournissent des types de base.
    Je pensais tout de même pouvoir me passer de certaines précisions élémentaires puisqu'à la limite on pourrait même considérer JavaScript comme un langage à typage statique, si on considère le type de base des variables comme étant des références mémoires. Quand je dis que JavaScript n'est pas typé, je présuppose que le lecteur a un minimum de culture informatique.

    Le typage dynamique a des cas d'utilisations légitimes, d'où le type Any en TypeScript. Le duck-typing peut également s'avérer très utile, par exemple pour parser des structures d'objets composés à partir d'une description sérialisée comme un JSON. Il n'y a donc pas de solution unique et parfaite, chacun des choix de typage a ses avantages et ses inconvénients. Le mieux est encore d'avoir le choix, et TypeScript est assez souple là-dessus.
    Pour être honnête, à part la lecture d'une collection de données peu ou pas structuré, il y a peu d'autres situations où le typage dynamique est pertinent et apporte une souplesse bienvenue par rapport à un typage statique qui de toute façon pourrait traiter ce même flux de données.

    Il n'y a pas de régression de mentalités, juste des adeptes qui considèrent leurs choix techniques comme unique vérité: "le typage dynamique c'est une idée à la con", "le typage statique ça sert à rien" etc... . Et c'est valable pour pleins d'autres sujets en informatique, les paradigmes de programmation, les conventions de code...
    Pourtant... Dans les communautés utilisatrices de JavaScript que je fréquente, j'ai pu observé un fort rejet du typage statique simplement parce que JavaScript n'est pas statiquement typé. Les autres détracteurs du typage étant souvent ceux qui n'aiment pas Microsoft et donc n'aiment pas TypeScript et donc n'aiment pas le typage (sisi, c'est le raisonnement que je peux lire régulièrement).

    Tout comme avant ES6, c'était la croix et la bannière pour faire reconnaître à nombre de développeurs JavaScript la notion de classe, simplement parce que la notion de classe était absente de JavaScript.

    C'est pourquoi, je maintiens qu'il y a bien eu une régression des mentalités à cause de JavaScript, même si ce n'est pas la faute du langage en lui-même, mais de ses défenseurs qui le considèrent comme l'alpha et l'oméga du développement (sur le Web).

  15. #15
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Non, soyons précis sur les définitions : JavaScript est un langage interprété dont les types sont vérifiés à l'exécution: c'est du typage dynamique, et en aucun cas du typage statique. Tout comme Bovino voulait faire passer il y a quelques temps le typage JS comme un typage fort, non ce n'est pas un typage fort si on peut affecter une valeur de type différent à une variable typée sans levée d'exceptions. Il n'y a pas de place possible à l'interprétation ici.

    Je ne compte pas rouvrir l'éternel débat du dynamique vs statique, il y a déjà des pages et des pages de discussion sur le net pour ça, et sans forcément de relation avec JavaScript ; pendant mes études c'était le camp Python qui affrontait le camp C++ à ce sujet. On sait que ça se résume à un compromis sûreté/flexibilité, on sait que ça a une incidence sur l'outillage associé (compilateur/inférence/optimisation), et on sait que l'un ou l'autre n'empêche pas de réaliser des merveilles ou de se planter royalement.

    Pour ma part, si je considère comme toi que le typage JS est parfois trop laxiste, je trouve également que TypeScript ne m'aide pas à prévenir la plupart des erreurs de type que je rencontre, car elles se produisent à l'exécution depuis des sources non prédictibles: back-end, API externes, saisies utilisateur... C'est pour ça que j'ai travaillé sur ma propre solution de typage dynamique fort, ObjectModel. Mais je ne l'utilise pas partout, seulement en cas de besoin.

    Concernant les classes, je suspecte un appel au troll vu ma dernière publication sur le sujet Si des gens veulent bricoler avec des classes en JavaScript, c'est leur choix, mais on ne m’enlèvera pas de la tête l'idée que JavaScript est un langage orienté prototype et que les deux concepts ne peuvent pas cohabiter correctement. Ah, et si les développeurs pouvaient reconnaître la notion de prototype, ça serait aussi un grand pas en avant.

  16. #16
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2013
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2013
    Messages : 242
    Points : 661
    Points
    661
    Par défaut
    L'un des points centraux de TypeScript, depuis le début, est la définition d'interfaces. Les interfaces en TS remplacent JSDoc en plus efficace : elles sont réutilisables, elles peuvent par exemple définir le contenu d'un objet passé en paramètre à une fonction. Certes, les interfaces TS peuvent être implémentées par des classes (en POO classique avec les classes ES6), mais elles se marient également très bien avec une programmation dynamique à base d'objets, de tableaux, de mixins.

  17. #17
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2013
    Messages
    242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2013
    Messages : 242
    Points : 661
    Points
    661
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Pour ma part, si je considère comme toi que le typage JS est parfois trop laxiste, je trouve également que TypeScript ne m'aide pas à prévenir la plupart des erreurs de type que je rencontre, car elles se produisent à l'exécution depuis des sources non prédictibles: back-end, API externes, saisies utilisateur... C'est pour ça que j'ai travaillé sur ma propre solution de typage dynamique fort, ObjectModel.
    Ce n'est pas le même besoin.

    Ce que permet TypeScript :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    interface Person {
    	id: number;
    	name: string;
    }
    function displayPerson(p: Person) {
    	console.log(p.name); // autocompletion on "p." here
    }
    Le paramètre "p" peut être construit comme on veut : un objet écrit en dur, un mixin, un objet héritant ses propriétés par prototype, l'instance d'une classe… En cas d'appel avec un objet créé dynamiquement, le compilateur demandera juste qu'on lui précise que l'objet est bien "Person".

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    let obj1 = {};
    obj1['id'] = 12;
    obj1['name'] = 'John'; 
    displayPerson(<Person>obj1); // on précise le type du paramètre
     
    let obj2 = {id: 12, name: 'John'};
    displayPerson(obj2); // le type est validé de manière statique
    TypeScript remplace avantageusement la plupart des annotations ou encore le préfixage par underscore des méthodes privées.

    Ce que permet ObjectModel :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    let Person = new Model({
    	id: Number,
    	name: String
    });
    let p = new Person(JSON.parse(/* some JSON here */)); // error if invalid
    p.name = 123; // type error at execution time
    ObjectModel est utile pour définir des modèles (au sens MVC) et les faire respecter.

  18. #18
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Non, soyons précis sur les définitions : JavaScript est un langage interprété dont les types sont vérifiés à l'exécution: c'est du typage dynamique, et en aucun cas du typage statique. Tout comme Bovino voulait faire passer il y a quelques temps le typage JS comme un typage fort, non ce n'est pas un typage fort si on peut affecter une valeur de type différent à une variable typée sans levée d'exceptions. Il n'y a pas de place possible à l'interprétation ici.
    Sans vouloir te vexer, tu ne vas pas m'apprendre la différence entre le typage statique et dynamique et je te suspecte à mon tour de vouloir troller à ce sujet.
    JavaScript n'est pas typé statiquement et c'est bien ce qu'il faut entendre par mon discours précédent sur le typage.

    Pour ma part, si je considère comme toi que le typage JS est parfois trop laxiste, je trouve également que TypeScript ne m'aide pas à prévenir la plupart des erreurs de type que je rencontre, car elles se produisent à l'exécution depuis des sources non prédictibles: back-end, API externes, saisies utilisateur... C'est pour ça que j'ai travaillé sur ma propre solution de typage dynamique fort, ObjectModel. Mais je ne l'utilise pas partout, seulement en cas de besoin.
    Tu peux utiliser ta solution avec TypeScript. Ce n'est pas parce que TypeScript résout une partie des problèmes qu'il prétend les résoudre tous.

    Concernant les classes, je suspecte un appel au troll vu ma dernière publication sur le sujet Si des gens veulent bricoler avec des classes en JavaScript, c'est leur choix, mais on ne m’enlèvera pas de la tête l'idée que JavaScript est un langage orienté prototype et que les deux concepts ne peuvent pas cohabiter correctement. Ah, et si les développeurs pouvaient reconnaître la notion de prototype, ça serait aussi un grand pas en avant.
    Absolument aucune allusion à la publication en question même si j'y vois la confirmation de mes affirmations sur une certaine vision un peu étroite de bon nombre de développeurs JavaScript. L'héritage orienté prototype et celui basé sur les classes ne recouvrent pas les même problématiques, ce n'est pas une raison pour exclure l'un ou l'autre. Néanmoins, pourquoi refuser le concept de classe alors que l'expérience a montré qu'il s'agit d'une notion très utile pour modéliser nombre de problème et qu'il existe tout un outillage autour de ça (génération automatique de code).

  19. #19
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Je ne trolle personne, c'est toi-même qui a dit que JS pouvait être considéré comme statiquement typé, juste avant de dire le contraire. J'ai peut-être l'esprit étroit mais je tenais à mettre les points sur les i.

    En pratique, je ne vois pas comment utiliser conjointement TypeScript et ObjectModel. Typer à la fois statiquement et dynamiquement n'a pas de sens, on combine les inconvénients et on perd les avantages.

    Pour répondre à ta question sur l'exclusion des classes, il s'agit du point X dans l'article. J'ai vécu la même expérience que celle décrite par Elliott.

  20. #20
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Ma première allusion sur JavaScript typé statiquement était une joke, même si je pensais que c'était assez évident... Passons donc.

    Sur le chapitre X de l'article en question, l'auteur a une vision un peu vieillotte des classes. Il serait bon qu'il se mette à la page. Il y a eu beaucoup de progrès depuis. Notamment le concept de classes partielles qui permet de faire de l'héritage par concaténation. Certes, ce n'est pas encore disponible sur TypeScript, mais vu que cela existe sur C# et qu'il s'agit d'une feature demandé par nombre d'utilisateurs de TypeScript, je pense qu'elle devrait voir le jour tôt ou tard.

Discussions similaires

  1. [INFO] Gestion d'un environnement TEST / PRODUCTION
    Par nuke_y dans le forum Oracle
    Réponses: 19
    Dernier message: 05/08/2005, 16h14
  2. Tests Unitaires - Production de documents
    Par giviz dans le forum Test
    Réponses: 13
    Dernier message: 07/02/2005, 08h41
  3. Choix d'un sgbd open source pour de la production
    Par gueeyom dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 14/05/2004, 11h40

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