Les développeurs peuvent désormais récupérer la version 1.6 du langage TypeScript. Il s’agit pour rappel d’un sur-ensemble typé du JavaScript, conçu initialement pour aider à la gestion des gros projets. Parmi les améliorations, on notera en particulier la possibilité de définir une classe à l’aide d’une expression.
TypeScript 1.6 permet donc de déclarer une classe avec une expression, qui peut d’ailleurs être anonyme. Microsoft, à l’origine de ce langage (libre et open source), indique que cet ajout fait suite au travail de compatibilité pour aligner le socle fonctionnel avec le standard ECMAScript 6.
La nouvelle version permet également la création d’un nouveau type composite, résultant d’un mélange entre deux autres types. Cette intersection de types diffère de l’union qui était déjà possible, mais dont le fonctionnement pouvait se révéler problématique si les développeurs souhaitaient simplement fusionner des types génériques. Les intersections peuvent se créer via le nouvel opérateur « & ».
Les classes abstraites ou partiellement abstraites font elles aussi leur apparition, Microsoft précisant d’ailleurs qu’il s’agit d’une fonctionnalité réclamée depuis longtemps par les développeurs. Même chose pour les alias de types génériques et des gardes de types personnalisées. Avec ces dernières, les développeurs pourront définir leurs propres gardes de types via des fonctions et le mot « is ».
TypeScript 1.6 peut être téléchargée pour Visual Studio 2015, Visual Studio 2013 ou en tant que paquet NPM. Ses sources sont également disponibles sur GitHub.
Commentaires (31)
#1
Ça fait plaisir de voir ce langage progresser de plus en plus vite au rythme que sa popularité augmente.
La syntaxe et l’aspect “transpilateur de JS” me rebutait pas mal au debut (par rapport à dart), mais je songe de plus en plus à m’y mettre…
#2
J’utilise TypeScript depuis quelques mois et c’est vraiment bien. Quel dommage de ne pas avoir mis les types non-nullable : https://github.com/Microsoft/TypeScript/issues/185
Microsoft a bien change : code source sur GitHub, lancement d’un éditeur multiplateforme - mais malheureusement pas open source - Visual Studio Code (qui n’a rien a voir avec Visual Studio), C# en open source… Ca va dans le bon sens. Ils sont presents la ou on ne les attendait pas il y a encore peu de temps.
Quelqu’un a essaye le concurrent de TypeScript : Flow de Facebook ? (qui lui gere les types non-nullable)
#3
AngularsJS 2 est écrit en Typescript donc si vous faites du développement Web, il va falloir s’y mettre …
#4
Comme concurrent tu as babeljs.io
#5
Marrant qu’un produit Google utilise une techno Microsoft. ^^
#6
#7
#8
Non, parce que:
- rien ne garantie que angular 2 deviendra aussi populaire que angularjs (y’a d’autres alternatives qui sont sorties entre temps)…
-On peut utiliser angular 2 en js, meme si, celon le dernier sondage une majorité ecrasante de gens l’utilisent en ts (mais faut etre logique, les gens qui utilisent des framework en beta sont pas du genre “conservateur”, donc normal qu’ils utilisent tous “le langage alternatif nouveau”…)
#9
#10
Il est possible de combiner du CoffeeScript et du TypeScript ? Je préfère l’écriture Coffee mais j’aimerais bien le typage fort de typeScript.
#11
On sait pas faire du JS du coup on remet des types dedans, mouai, pas prêt de m’y mettre moi.
#12
On disait la même chose de jQuery à l’époque pour le dev web. Aujourd’hui, il y a eu forte tendance à s’en débarrasser. Qui dit que ça ne sera pas la même chose avec Angular hein ? :)
#13
#14
Je fait mon rabat-joie, mais vous faites une new pour TypeScript 1.6, mais pas pour Node 4.0.0, je suis pas sur de comprendre la logique :p
#15
Il y a quand même une grande différence entre une application Angular et JQuery. Angular est basé sur les composants, a des services bien définis, un moteur de template intégré, un système de routage…
C’est aussi bien plus facile de ne pas utiliser jQuery en 2015 qu’en 2007. Les navigateurs actuels respectent beaucoup mieux les standards et on des comportements plus uniformes. Les APIs JavaScript natives sont aussi plus complètes. document.querySelector est arrivé bien après jQuery par exemple.
Pour finir : tendances entre jQuery et AngularJS sur Google Search
#16
#17
#18
>> La nouvelle version permet également la création d’un nouveau type composite, résultant d’un mélange entre deux autres types.
C’est quand même marrant. D’un côté “on” passe sa vie à hurler que l’héritage multiple c’est le mal absolu, et d’un autre côté les mêmes “on” s’ignénient à ajouter à presque tous les langages de programmation une technique détournée pour faire quand-même de l’héritage multiple sans vraiment l’avouer…
#19
Ou pas. Pour l’instant c’est en alpha, il y a plein de choses qui changent de jour en jour, donc à moins de vouloir participer à son développement, rien de sert de courir, il vaut mieux attendre que ce soit stabilisé (en béta).
#20
#21
#22
#23
#24
C’est pour cela que j’insiste sur le fait qu’on se place dans le cas de types immu(t)ables. Dans ces conditions, la dérivation de classes définit des sous-types selon le principe de substitution de Liskov.
#25
Flow me semble plus interessant parce qu’il se limite a apporter le type checking (et type inference) alors que Typescript apporte aussi des choses en plus comme les interfaces. TS a maintenant absorbe ES6, du coup certaines des fonctionalites qu’ils apportaient par dessus ES5 sont un peu dedoublees, c’est confus je trouve. Et perso ES6 apporte deja tout ce que je veux.
De plus Flow semble plus malin, il peut avertir des mauvais usages de la valeur “null” par exemple.
En gros aujourd’hui je partirais sur Flow parce que c’est facile d’y passer ou de l’enlever sans modifier quoi que ce soit d’autre que les types dans le code (et encore: babel les enleve lui meme, il n’y a rien a faire !)
#26
Rendre l’instance non-mutable c’est juste de la magouille pour éviter d’appliquer des opérations du rectangle sur un carré (par polymorphisme)… et au final de ne plus avoir un carré.
Ca veut dire que le polymorphisme n’est pas applicable car le carré n’a pas de la même “forme” qu’un rectangle, et donc que l’héritage est mal employé.
#27
Un entier est non mutable, il s’agit donc uniquement d’une magouille pour éviter qu’il devienne un flottant ?
L’immutabilité est un des principes fondamentaux de la programmation fonctionnelle, simplifie le multithreading, le map/reduce, mais tu dois avoir raison, ces techniques c’est une magouille inventée par ceux qui ne savent pas correctement gérer les conditions de course dans un programme.
#28
C’est vrai que dans le cas Rectangle et Carré une simple fonction/propriété genre “isSquare” peut suffire ^^”
" />
" /> ; attention, sans laisser passer n’importe quoi non plus 
" />
Après ca dépend toujours du code et du programme à coder derrière aussi… parce que la classe Rectangle peut aussi disparaitre au profit de Parallélogramme
Je pense quand même que le mieux est un code lisible et compréhensible au final; il faut parfois savoir mettre son égo de coté pour pouvoir travailler en équipe dans de bonnes conditions
#29
Je parlais uniquement du cas présent, c’est à dire rendre l’instance non-mutable pour conserver la sémantique des propriétés géométriques d’un Carré et d’un Rectangle.
" />
Bien sur, avoir des instances non-mutables n’est pas une magouille en soi. Quoiqu’en terme purement objet, ce n’est pas une nécessité pour avoir un programme fonctionne. C’est plutôt un moyen de dire au compilo/runtime “hey, la valeur des attributs ne sera pas modifiée: tu peux vérifier à la compilation que je ne modifie pas les valeurs ? Ah, et tu pourras optimiser les appels au runtime ? Merci.”
#30
Tout dépend de l’usage, comme disait Cicéron.
Et Cicéron, c’est pas un carré.
#31