La version finale de TypeScript 2.0 est disponible

La version finale de TypeScript 2.0 est disponible

Pour accompagner Angular 2

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

23/09/2016 3 minutes
81

La version finale de TypeScript 2.0 est disponible

Microsoft a publié la version 2.0 de TypeScript, un surensemble de JavaScript. Plusieurs nouveautés importantes sont au programme, notamment les types « non-nullable », l’analyse du flux de contrôle ou encore la déclaration simplifiée des modules.

TypeScript est un langage conçu pour gérer de gros projets. Créé par Microsoft et open source (environ 150 contributeurs), il rencontre un certain succès, la récente arrivée d’Angular 2 – dont il accompagne presque la sortie – ne pouvant que le renforcer puisqu’il en devient le langage recommandé. Il s’agit d’un surensemble de JavaScript, dont il reprend l’ensemble des capacités et avec lequel il est totalement compatible.

Pour bien comprendre l’intérêt de TypeScript, il suffit de rappeler qu’il est transpilé de manière statique. Dans un tel cas, c’est le compilateur qui s’occupe de vérifier les erreurs lorsqu’il passe le code à la moulinette. Une différence de taille avec le JavaScript classique où les erreurs ne sont vérifiées qu’à l’exécution du code. Un gain que l'on retrouve avec d'autres langages tels que C++, C# ou Java.

Interdire les valeurs null et undefined

La principale nouveauté de TypeScript 2.0 est un contrôle plus important des valeurs null pour les développeurs. Le type « non-nullable » permet donc à ces derniers de déclarer des variables qui ne pourront jamais renvoyer une valeur null ou undefined.

Cette déclaration reste à l’appréciation du développeur. En ajoutant le flag « --strictNullChecks » à son projet, il interdit explicitement à toutes les déclarations de variables qui suivent de renvoyer autre chose que leur type, string ou number par exemple. Mais si une variable doit justement pouvoir retourner des valeurs null ou undefined ? De nouveaux types font justement leur apparition, avec les mêmes noms. Notez par ailleurs qu’un opérateur « ! » permet de supprimer ces types de toute expression.

Ces nouveautés à elles seules peuvent permettre une chute importante du nombre d’erreurs dans le code. D’autant que si chaque variable est soigneusement déclarée, le compilateur peut en conséquence détecter d’autres types d’erreurs, notamment les variables qui ne sont jamais initialisées.

Flux de contrôle et déclaration simplifiée des modules

Signalons deux autres apports important. D’une part, la possibilité de déclarer des modules de manière simplifiée. Plus besoin de préciser certaines informations, « declare module "foo"; » étant par exemple suffisant. D’autre part, la CFA (control flow analysis) qui permet de suivre à la trace l’évolution des types dans un programme.

Attention, son utilisation dans Visual Studio 2015 ou Visual Studio Code réclame la dernière mise à jour disponible de chaque environnement de développement.

81

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Interdire les valeurs null et undefined

Flux de contrôle et déclaration simplifiée des modules

Commentaires (81)


“transpilé” vraiment ? ça veut dire quoi en fait ?



Quant à un compilateur qui peut détecter les variables non initialisées, quelle nouveauté !








fred42 a écrit :



“transpilé” vraiment ? ça veut dire quoi en fait ?



Quant à un compilateur qui peut détecter les variables non initialisées, quelle nouveauté !





TypeScript est converti en Javascript



Je voulais surtout critiquer ce nouveau mot et son utilisation sans recul dans l’article.

Parce que une phrase comme celle-là :

“Pour bien comprendre l’intérêt de TypeScript, il suffit de rappeler qu’il est transpilé de manière statique”,

ça ne m’aide pas à comprendre, vraiment pas !


Tout à fait d’accord : ce néologisme est un sous-ensemble de “compiler” en ne faisant qu’ajouter des conditions sur l’objet de destination.



Aussi inutile & contre-productif que d’inventer “fruitiger” à la place de “manger” lorsque l’on parle d’un fruit. On peut aller très loin en déclinaisons.

Et ce n’est même pas pour paraître moderne vu que ce mot ne semble pas nouveau (je suis remonté jusqu’à juin 2012 pour le moment). Est-ce donc pour paraître expert ?



TypeScript compile en JavaScript car on passe d’un langage à un autre. Point.








fred42 a écrit :



“transpilé” vraiment ? ça veut dire quoi en fait ?



Quant à un compilateur qui peut détecter les variables non initialisées, quelle nouveauté !









 Convertir un code d’un langage à un autre. J’avoue que c’est pas un mot qu’on entend souvent. On parle plus souvent de conversion ou d’adaptation.



Après selon le langage, on compile pour passer du langage X vers un langage machine. Donc j’avoue que j’ai jamais compris ce nouveau mot.



 



 



De ton point de vue.



 Transpiler apporte l’information nécessaire à l’opération effectuée la où compiler serait trop générique.


C’est pas particulièrement nouveau, c’est juste qu’on le voit plus souvent avec tout ce qui est TS, Dart, Babel, etc, mais ça vait déjà quelques années que tu peux trouver ce terme (Je me souvient avoir utilisé ce terme à l’époque où je bossais sur GWT il y a bien 4 ans déjà). Il s’agit simplement de passer d’un code source à un autre.



Après j’avoue que le paragraphe dans l’article est pas clair.



“de manière statique”, c’est à dire? Pas à la volée dans le navigateur? Effectivement tout est transpilé en JS avant d’envoyer en prod (enfin même pour tester de toute façons).

Et pourquoi parler de compilateur quand on parle de transpiler? Un transpileur transpile et un compilateur compile (à la limite transcompilateur mais c’est moche)








fred42 a écrit :



“transpilé” vraiment ? ça veut dire quoi en fait ?



ça veut dire qu’il est “transpiré” et “épilé” : c’est une contraction des deux mots.



c’est pour limiter les odeurs d’aisselles des développeurs en plein effort dans les open space.



C’est un mot assez utilisé dans la sphère javascript où quelques langages propose ce mécanisme de transpilation.  C’est un mot anglais repris en français.




Pour bien comprendre l’intérêt de TypeScript, il suffit de rappeler qu’il est transpilé de manière statique.





Ah mais c’est bien sûr ! C’est tellement évident !



<img data-src=" />



Tout le monde s’extasie devant ça, mais je ne comprends pas vraiment à quoi ça sert, surtout quelle est la valeur ajoutée dans un “sur-ensemble” par rapport à du JS natif..



Edit : je vois que je ne suis pas le seul à tiquer sur cette “explication” <img data-src=" />


Encore un outil pour mâcher le travail des dévs…alors qu’ils passent leur journée à faire des simples copier/coller et se plaignent du marketing ou du commercial alors qu’ils ne sont pas fichus de sortir une appli sans bugs. <img data-src=" />


&nbsp;On est pas très éloigné de la réalité en fait <img data-src=" />


Oui, ya pas beaucoup de dévs transpilé selon cette définition <img data-src=" />








Jarodd a écrit :



Tout le monde s’extasie devant ça, mais je ne comprends pas vraiment à quoi ça sert, surtout quelle est la valeur ajoutée dans un “sur-ensemble” par rapport à du JS natif..







Clairement je saisis pas trop non plus. J’ai voulu essayer pourtant mais j’accroche pas du tout. Je trouve que ça rend la vie des devs bien plus compliquée que ça ne l’arrange.



Faisant pas mal de Java je m’étais dis qu’avoir un langage typé pourrait être cool, mais au final il est très probable d’utiliser à un moment des libraries JS qui n’ont pas été pensées en TS et du coup c’est à peu près inutile à moins de se faire chier à maintenir sois même les TSD qu’on va probablement devoir rédiger à partir de docs très maigres. De plus je n’aime pas l’idée de faire confiance à un programme pour rédiger le code final de mon appli. Bref franchement j’ai juste la sensation que c’est contre nature cette façon de faire. Le JS n’a pas été pensé comme ça, pourquoi faire comme si?



Perso je préfère me focaliser sur les nouveautés de JS et bien les connaitre. Parce que c’est le souci avec ces sur-couches aussi, si ça se généralise les devs sauront de moins en moins où en est JS (oui on peut faire du JS dans TS, mais quand on utilise TS, le but c’est de faire du TS, pas du JS)



Il te manque un analyste… C’est pour ca.


Parfois le cahier des charges est pourri, parfois le dév fait son truc mais ne pose pas de questions “logiques”, parfois les commerciaux vendent des fonctionnalités inexistantes mais dans leur tête c’est une simple adaptation.



Bref les problèmes sont nombreux et très variés, mais chacun cherche toujours un autre sur qui il pourra rejeté la faute.








gogo77 a écrit :



Clairement je saisis pas trop non plus. J’ai voulu essayer pourtant mais j’accroche pas du tout. Je trouve que ça rend la vie des devs bien plus compliquée que ça ne l’arrange.



Faisant pas mal de Java je m’étais dis qu’avoir un langage typé pourrait être cool, mais au final il est très probable d’utiliser à un moment des libraries JS qui n’ont pas été pensées en TS et du coup c’est à peu près inutile à moins de se faire chier à maintenir sois même les TSD qu’on va probablement devoir rédiger à partir de docs très maigres. De plus je n’aime pas l’idée de faire confiance à un programme pour rédiger le code final de mon appli. Bref franchement j’ai juste la sensation que c’est contre nature cette façon de faire. Le JS n’a pas été pensé comme ça, pourquoi faire comme si?



Perso je préfère me focaliser sur les nouveautés de JS et bien les connaitre. Parce que c’est le souci avec ces sur-couches aussi, si ça se généralise les devs sauront de moins en moins où en est JS (oui on peut faire du JS dans TS, mais quand on utilise TS, le but c’est de faire du TS, pas du JS)





Le JS n’a pas été “pensé” tout court. Comme la plupart des languages webs son évolution est controlée par des tas de facteurs ce qui rend le développement pas toujours logique ou parfait, malheureusement.



Et sinon, des tas de languages / framework fonctionnent comme ça … pour n’en citer qu’un, prenons Unity3D. Tu code en C# mais sur les plateformes mobiles (et bientôt PC) ton code est transpilé en C++ via L2CPP.&nbsp;



Par contre oui, rester au courant des évolutions natives du JS c’est nécessaire. Ce qui n’empêche nullement d’utiliser TS pour aller plus vite.



Rien que le check via le compilo c’est un timer saver de dingue.



Tu peux notamment à langage constant définir vers quelle version de javascript tu souhaites transpiler ton typescript.



Quand ton navigateur cible n’est compatible qu’avec ecmascript 5, c’est un plus.


Oui mais ça c’est déjà possible de JS à JS donc TS n’apporte rien là dessus. Du coup c’est un peu léger comme motivation.








Jarodd a écrit :



Ah mais c’est bien sûr ! C’est tellement évident !



<img data-src=" />



Tout le monde s’extasie devant ça, mais je ne comprends pas vraiment à quoi ça sert, surtout quelle est la valeur ajoutée dans un “sur-ensemble” par rapport à du JS natif..



Edit : je vois que je ne suis pas le seul à tiquer sur cette “explication” <img data-src=" />





Tu vois la valeur ajoutée de C par rapport à l’assembleur ? ben là c’est la même idée.



La différence avec quelque chose comme Unity c’est que ce langage est au cœur de l’environnement qu’il propose. Il ne s’agit pas d’une tentative de rafistolage. Je ne m’en voudrait pas de ne pas être au top en CPP sur Unity parce que avec C# on sera toujours dans cet environnement cohérent.



Avec TS c’est juste un truc en plus, comme Dart, comme coffee script et surement d’autres qui fout le bordel parce que du coup personne n’utilise la même chose. Du coup un développeur va peut être être plus productif ponctuellement dans son propre cadre de travail, mais ça a un côté égoïste parce qu’il devient plus complexe de partager les avancées. Au final je trouve que ça s’éparpille et que ça rend le paysage encore plus bordélique qu’il ne l’était déjà. Quand tu vois que les gros projets s’amusent à maintenir des versions TS plus pure JS et que parfois il peut y avoir des petites diff d’un dépôt à l’autre ou que tu te retrouves avec des docs pas à jour selon le langage que tu choisis pour les exemples… bref j’aime l’idée, mais dans les faits j’ai du mal à trouver ça cool.


Personnellement j’ai cru lire TrueCrypt 2.0.



<img data-src=" />








RDeluxe a écrit :



c’est un timer saver de dingue.





Ca permet de sauver les timers ?



Et pendant ce temps, les koalas, personne ne s’en occupe des koalas. Pourtant c’est sympa les koalas. Mon beau-frère a d’ailleurs un ami qui a un pote koala, et…



… bref, <img data-src=" /> pour les koalas.



C’est vrai. Si c’était unifié, du genre sous python ou actionscript, et que les plus grandes entreprises ET projets open source l’utilisent, on aurait enfin un remplaçant d’ecmascript.


Dans les commentaires, il y a des gens qui s’en servent… J’ai pas l’impression vu ce que je lis. L’avantage de Typescript c’est que cela en fait un vraiment langage objet avec possible d’avoir un typage fort là où le javascript est un langage protoypé (que presque personne ne maîtrise) à typage faible. Ça permet de faire de grosse application JS sans trop se prendre la tête, surtout quand on vient de l’objet. Après, on perd pas mal de ce qui fait la force de JS, comme le protypage (que je ne m’amuserait pas à expliquer ici).



Ça reste une actu pour les dévs web, pas forcement accessible pour ceux qui n’ent font pas.








Berbe a écrit :



Tout à fait d’accord : ce néologisme est un sous-ensemble de “compiler” en ne faisant qu’ajouter des conditions sur l’objet de destination.



Aussi inutile & contre-productif que d’inventer “fruitiger” à la place de “manger” lorsque l’on parle d’un fruit. On peut aller très loin en déclinaisons.

Et ce n’est même pas pour paraître moderne vu que ce mot ne semble pas nouveau (je suis remonté jusqu’à juin 2012 pour le moment). Est-ce donc pour paraître expert ?



TypeScript compile en JavaScript car on passe d’un langage à un autre. Point.





Peut-on parler de compilation quand on produit un script en phase finale (Ce sera encore interprété à l’exécution)?

&nbsp;



Si tu rajoutes un transpileur comme Babel effectivement.





  • les types : la verification statique que cela permet, les aides aux développements si ton IDE le supporte (completion plus simple, refactoring…)


“Interdire les valeurs null et undefined”



Entre les try et les catch, 80% du code est basé sur ce principe, au risque que l’appli plante <img data-src=" />








zefling a écrit :



Ça permet de faire de grosse application JS sans trop se prendre la tête, surtout quand on vient de l’objet.





Désolé mais ce n’est pas mon avis. J’ai fait un projet entier en js et comme seule dépendance JQuery pour le DOM. Mais toute la logique était en plain js . Comme tout projet dont on est l’auteur et seul à bosser dessus, ça commence bien, organisé, presque académique. Ca souffrait parfois de prototypages et de refontes pour combler les failles dans les anciens codes avec l’expérience acquise, mais ça allait bien. Surtout que c’était un projet qui n’avait pas vraiment de deadline et pas de pression au début. Mais ça a tout de même fini en un projet impossible à maintenir, car la structure ne tenait pas face aux demandes des clients et la direction qui me poussait à accepter tous les changements. Et j’ai alors vu le problème du prototypage de javascript, surtout pour le debug. Dieu que j’étais content de revenir à du compilé bien strict du genre java. J’ai compris ce qu’était le compromis entre flexibilité et stabilité pour perdre le moins de temps.



[MaLife]

&nbsp;Moi au boulot je transpile du C++ en javascript avec emscripten <img data-src=" />

[/MaLife]


Etant donné que le C# a des capacités à être utilisé en script (encore plus depuis Roslyn), ça serait intéréssant que Microsoft fasse un geste (sur Edge par exemple) pour proposer C# en alternative à JS. Et ça ferait plaisir aux dev en ASP.NET, vu qu’ils pourront utiliser C# des 2 côtés.

Parce que bon je veux pas dire, mais parler de web ouvert quand tout est limité à un seul language, du moins sur le front-end (HTML, CSS, JS), bof hein&nbsp;<img data-src=" />








vargace a écrit :



[MaLife]

&nbsp;Moi au boulot je transpile du C++ en javascript avec emscripten <img data-src=" />

[/MaLife]





Le problème avec ça c’est que tu peux sûrement pas utiliser les 34 des fonctionnalités du langage. J’imagine que si je ramène ma bibliothèque de sérialisation qui repose que sur des template&lt;&gt;, emscripten va se faire dessus.









fred42 a écrit :



“transpilé” vraiment ? ça veut dire quoi en fait ?







Que c’est LGBT friendly.



Lespilé, Gaypilé, Bipilé, Transpilé….



Avec ton raisonnement, il faudrait alors revenir aux 1000 prises électriques différentes, une par marque, pour avoir le choix.


Y’a pas de mal à avoir du choix. JS a beau être populaire, n’empêche que pour écrire du code qui fonctionne correctement, c’est une vraie galère, puisque justement le principe même du langage est qu’il n’y a pas de “cadre”, tout est possible. Peut-être que dans l’idée c’est une bonne chose, mais la réalité prouve que pas vraiment, autrement y’aurai pas des surplus du genre TypeScript, Dart et j’en passe.



Y’a la liberté dans le développement logiciel, je vois pas trop pourquoi on ne devrait pas en avoir dans le développement web.


C’est plus que la possibilité d’avoir un typage fort, car sans le support des types, il perd énormément de son intéret.



J’inverserai la phras: Il permet d’avoir un typage faible.








zefling a écrit :



Typescript c’est que cela en fait un vraiment langage objet avec possible d’avoir un typage fort là où le javascript est un langage protoypé (que presque personne ne maîtrise) à typage faible.







on perd pas mal de ce qui fait la force de JS, comme le protypage (que je ne m’amuserait pas à expliquer ici).



Je ne peux que plussoyer: malheureusement beaucoup n’ont pas vraiment compris qu’une bonne partie de la puissance du JS repose sur l’“orienté prototype” qui n’est pas de “l’orienté objet” comme les autres.



Ceux qui viennent de C#/C++/Java et qui n’ont pas encore pris le temps de creuser le sujet croient souvent un peu vite que JS n’est qu’une sorte de “version mal faite” des langages et principes qu’ils ont l’habitude de manipuler. Or c’est une erreur fondamentale. Un peu comme si un charpentier disait que les tournevis caynul parce que ça permet pas de bien planter des clous.



Par contre, une fois qu’on a bien intégré les principes de l’“orienté prototype”, on comprend beaucoup plus de choses et que cette approche a ses atouts qu’on ne retrouve pas ailleurs (chose qu’il est impossible de détailler ici ; il y a des ebooks, comme celui de Douglas Crockford qui sont là pour ça).







Nb5 a écrit :



Le problème avec ça c’est que tu peux sûrement pas utiliser les 34 des fonctionnalités du langage. J’imagine que si je ramène ma bibliothèque de sérialisation qui repose que sur des template&lt;&gt;, emscripten va se faire dessus.





Je pense qu’au contraire les templates C++ doivent passer sans le moindre souci. La transpilation ‘quelquechose vers JS’ se fait sur la base du jeu d’instructions LLVM, qui arrive donc bien après que les templates aient été ‘interprétés’ par le compilo.



Regarde la liste d’exemple de choses qui ont été portées, c’est assez impressionnant.



Au passage, à partir du moment où on peut transformer du code d’un langage quelconque en LLVM (typiquement via Clang, qui supporte pas mal de langages), c’est gagné, on peut en faire du JS.









brazomyna a écrit :



Je ne peux que plussoyer: malheureusement beaucoup n’ont pas vraiment compris qu’une bonne partie de la puissance du JS repose sur l’“orienté prototype” qui n’est pas de “l’orienté objet” comme les autres.



Ceux qui viennent de C#/C++/Java et qui n’ont pas encore pris le temps de creuser le sujet croient souvent un peu vite que JS n’est qu’une sorte de “version mal faite” des langages et principes qu’ils ont l’habitude de manipuler. Or c’est une erreur fondamentale. Un peu comme si un charpentier disait que les tournevis caynul parce que ça permet pas de bien planter des clous.







En javascript les différentes facons de créer une simili class avec héritage et tout le toutim&nbsp; montre sa puissance mais aussi sa faiblesse.&nbsp;



&nbsp;Js permet de faire beaucoup de choses de différentes facons, c’est super, mais absolument pas structurant.&nbsp;

&nbsp;



J’avais pensé à ce genre d’explication.








gogo77 a écrit :





&gt; […] se faire chier à maintenir sois même les TSD



Les autres ont deja ecrit les .tsd pour toi :&nbsp;https://github.com/DefinitelyTyped/DefinitelyTyped



&gt; […] je n’aime pas l’idée de faire confiance à un programme pour rédiger le code final de mon appli.



LOL va au bout de ta logique et code en ASM…



&gt; […] Le JS n’a pas été pensé comme ça, pourquoi faire comme si?&nbsp;



Peut etre parceque c’est mieux ? permet d’eviter des bugs et de “documenter” son code.



&gt; […] si ça se généralise les devs sauront de moins en moins où en est JS



N’importe quoi. TypeScript = JavaScript + typage. Si le fait d’ajouter du typage a ton code (let toto: number vs let toto) te fait oublier ton JavaScript, oublie la programmation.



Non je vois pas, désolé <img data-src=" />








Nithril a écrit :



En javascript les différentes facons de créer une simili class avec héritage et tout le toutim&nbsp; montre sa puissance mais aussi sa faiblesse.





classes, héritage, instances, tu illustres exactement ce que je disais à propos des dev. OO qui n’ont pas encore totalament intégré ce qu’est l’“orienté prototype”. Pour faire (très très) simpliste: on ne définit plus des types qu’on instancie. On définit des espèces de modèles qu’on duplique.



Je le sais d’autant mieux que je suis passé par là moi aussi.









tanguy_k a écrit :



Les autres ont deja ecrit les .tsd pour toi : https://github.com/DefinitelyTyped/DefinitelyTyped







Merci je connais. C’est qui les “autres”? On peut leur faire confiance? Il y a tout? Tient c’est nouveau. Oh et biensûr il y a les TSD pour toutes les versions des librairies et elles sont mise à jour dès qu’il y a une nouveauté…







tanguy_k a écrit :



LOL va au bout de ta logique et code en ASM…







Merci pour ce commentaire tout à fait pertinent et sans la moindre condescendance… Sérieux t’as vraiment cru que c’était comparable?







tanguy_k a écrit :



Peut etre parceque c’est mieux ? permet d’eviter des bugs et de “documenter” son code.







C’est quoi mieux? Merci pour cet argument en carton ;) Sinon documenter c’était pas interdit avant l’arrivée de TS, mais soit, je veux bien admettre que ça peut rendre les choses légèrement plus claires de ce côté. Mais ceux qui avaient la flemme de faire de la doc auront toujours la flemme.







tanguy_k a écrit :



N’importe quoi. TypeScript = JavaScript + typage. Si le fait d’ajouter du typage a ton code (let toto: number vs let toto) te fait oublier ton JavaScript, oublie la programmation.







Ça va merci je m’en sort pas trop mal jusque là… Je t’accorde que c’est pas insurmontable de connaître TS tout en restant à jour côté JS mais des développeurs fainéants j’en connait plein… Et même si TS propose une syntaxe simple aujourd’hui qui sait ce qu’il en sera à l’avenir et les divergences seront peut êtres plus importantes qu’aujourd’hui. Si le fait d’ajouter une couche à ton environnement de dev ne te fais pas sourciller alors peut être que tu devrais programmer encore quelques années pour te rendre compte que ce n’est pas le genre de choix qu’on fait à la légère car l’INpact peut être énorme.





Bref, c’était pas la peine d’être aussi arrogant et sarcastique. Je n’ai jamais prétendu détenir la vérité, je donne mon point de vue et j’aimerai celui des autres pour mieux comprendre. Si tu n’a pas envie de remettre quoi que ce soit en question en matière de dev, ne fait pas ce métier stp.



Merci je connais, ça c’est la plomberie.&nbsp; In fine le prototypage va être utilisé pour mettre en places les paradigmes de la programmation orientée objet. Donc des “class” qui sont certes des fonctions mais qui sont nommées par convention en upper camel case, de l’héritage de toutes formes, une instance de cette pseudo classe, qui peut avoir un type avec les mécanismes….



Bref, c’est puissant, mais peu structurant. Typescript vient structurer tout cela.



Le modèle que tu dupliques, c’est une manière de faire. Tu peux aussi le faire par prototype qui ne possède pas l’inconvénient de la duplication.








gogo77 a écrit :



Ça va merci je m’en sort pas trop mal jusque là… Je t’accorde que c’est pas insurmontable de connaître TS tout en restant à jour côté JS mais des développeurs fainéants j’en connait plein… Et même si TS propose une syntaxe simple aujourd’hui qui sait ce qu’il en sera à l’avenir et les divergences seront peut êtres plus importantes qu’aujourd’hui. Si le fait d’ajouter une couche à ton environnement de dev ne te fais pas sourciller alors peut être que tu devrais programmer encore quelques années pour te rendre compte que ce n’est pas le genre de choix qu’on fait à la légère car l’INpact peut être énorme.





TS est un superset de JS. Il y a peu de chance (voir aucune) que TS diverge de JS pour cette raison. Les quelques demandes d’évolutions que j’ai pu voir avaient des commentaires du style “proposons d’abord cela à



ecmascript". Après il est certain qu'utiliser un framework basé sur&nbsp;  TS (au hasard Angular) aide beaucoup  à avoir des TSD à jour.    



&nbsp;



Cette techno est plus que prometteuse :)








gogo77 a écrit :



Merci je connais. C’est qui les “autres”? On peut leur faire confiance? Il y a tout? Tient c’est nouveau.&nbsp;





Donc si je comprend bien, tu te mefie d’un bete fichier de typage qui n’a aucune incidence de sortie (le *pilateur fais juste la verif, les types sont pas integrés) dans un milieu où les dev font du npm sur 300 paquets par projet?



(lol..)



Je ne me méfie pas plus. Mais si c’est pas fiable l’intérêt de TS est tout de même amoindri, non? C’est juste que je vois ça comme une charge de boulot supplémentaire alors qu’en JS je n’ai pas à me poser la question.


Oui effectivement je pense que tu as raison là dessus et que ce dont je parle n’arrivera probablement jamais. Et en fait je pense qu’à l’avenir c’est effectivement ES qui se rapprochera de ce que peut proposer TS.



Du coup j’imagine dans quelques années qu’il pourrait y avoir tout un tas de code TS qui traînera partout alors qu’il n’aura plus lieu d’être.


Quelqu’un aura-t-il un jour le courage de tuer Javascript.



Non parce que, à la base, le problème c’est quand même de coder directement en Javascript.








Nithril a écrit :



In fine le prototypage va être utilisé pour mettre en places les paradigmes de la programmation orientée objet. Donc des “class” qui sont certes des fonctions mais qui sont nommées par convention en upper camel case, de l’héritage de toutes formes, une instance de cette pseudo classe, qui peut avoir un type avec les mécanismes….





Ben non, justement. Sors de tes réflexes OO-class.





Le modèle que tu dupliques, c’est une manière de faire. Tu peux aussi le faire par prototype qui ne possède pas l’inconvénient de la duplication.



Non, le prototype n’est pas l’inverse de la ‘duplication’ ; c’est un moyen de réutiliser une fois par plein d’instances un élément commun. Ca n’a rien à voir avec la différence OO-classes/OO-prototype.





Merci je connais, ça c’est la plomberie.



Tes remarques démontrent que justement tu crois connaître, mais qu’en fait l’ensemble de ta réflexion reste totalement biaisée par ce que tu utilises depuis tellement longtemps que tu en oublies que ce n’est pas l’unique alternative (l’OO-classes).



Tu est exactement dans le cas du charpentier mentionné ci-avant.



Crois-moi:



1- Accepte de te détacher de tes ‘réflexes’ OO-class (sans doute ancrés depuis tellement longtemps et tellement de pratique, que tu en oublies que ce n’est pas l’unique alternative).



2- Prends le temps de lire des choses sur le JS, de comprendre vraiment la philosophie de ce qu’est l’oritenté ‘prototype’, en ne cherchant plus à systématiquement raccrocher ça à ce que tu connais (trop) bien.



Et ça ne pourra t’être que bénéfique au bout. Pas seulement pour avoir compris le JS ou l’OO prototype. Mais surtout parce que voir autre chose t’enrichit énormément même quand tu retournés à de l’OO ‘classique’, parce que tu ne considères plus tous ses préceptes comme totalement universels et immuables. Mais bien une façon de faire parmi d’autres, qui a ses avantages et … ses limites.




















brazomyna a écrit :



2- Prends le temps de lire des choses (…) de comprendre vraiment la philosophie de ce qu’est l’oritenté ‘prototype’, en ne cherchant plus à systématiquement raccrocher ça à ce que tu connais (trop) bien.





Cadeau.









brazomyna a écrit :



Ben non, justement. Sors de tes réflexes OO-class.





Non, le prototype n’est pas l’inverse de la ‘duplication’ ; c’est un moyen de réutiliser une fois par plein d’instances un élément commun. Ca n’a rien à voir avec la différence OO-classes/OO-prototype.

&nbsp;



Tes remarques démontrent que justement tu crois connaître, mais qu’en fait l’ensemble de ta réflexion reste totalement biaisée par ce que tu utilises depuis tellement longtemps que tu en oublies que ce n’est pas l’unique alternative (l’OO-classes).



Tu est exactement dans le cas du charpentier mentionné ci-avant.



Crois-moi:



1- Accepte de te détacher de tes ‘réflexes’ OO-class (sans doute ancrés depuis tellement longtemps et tellement de pratique, que tu en oublies que ce n’est pas l’unique alternative).



2- Prends le temps de lire des choses sur le JS, de comprendre vraiment la philosophie de ce qu’est l’oritenté ‘prototype’, en ne cherchant plus à systématiquement raccrocher ça à ce que tu connais (trop) bien.



Et ça ne pourra t’être que bénéfique au bout. Pas seulement pour avoir compris le JS ou l’OO prototype. Mais surtout parce que voir autre chose t’enrichit énormément même quand tu retournés à de l’OO ‘classique’, parce que tu ne considères plus tous ses préceptes comme totalement universels et immuables. Mais bien une façon de faire parmi d’autres, qui a ses avantages et … ses limites.




(désolé pour le doublon)

&nbsp;

&nbsp;Je n’ai pas dit que le prototype était l’inverse de la duplication. Je répondais à ton propos&nbsp; qui est réducteur et trop (trop) simpliste:

“Pour faire (très très) simpliste: on ne définit plus des types qu’on

instancie. On définit des espèces de modèles qu’on duplique. “.&nbsp;

Wikipedia a une definition juste:

Cloning refers to a process whereby a new object is constructed by copying the behavior of an existing object (its prototype).

&nbsp;

Je connais l’orienté prototype merci… Mon propos est plus haut niveau. Le prototype c’est la plomberie qui va permettre de mettre en place certains&nbsp; principes de l’orienté object notamment l’héritage…&nbsp; Que ce soit en utilisant un principe de class ou de prototype, le besoin derrière su cet aspect est le même. Bref, c’est puissant, mais peu structurant. Typescript vient structurer tout cela.



Je rappel mon propos initial:

“En javascript les différentes facons de créer une simili class avec

héritage et tout le toutim&nbsp; montre sa puissance mais aussi sa faiblesse.”. Tu peux ticker sur simili class.&nbsp; Ce besoin primaire de disposer d’un mécanisme de class et d’héritage a d’ailleurs été introduit avec ES6, cela reste du sucre syntaxique mais le mot est présent…



&nbsp;&nbsp;&nbsp;








Nithril a écrit :



Typescript vient structurer tout cela.







Non, il ne structure rien du tout vu que tu perds totalement la notion de prototype en TypeScript, et pour moi ça reste une sacrée perte. C’est même vraiment relou dans certain cas et je me retrouve à faire de façon compliqué ce que j’aurais pu faire simplement.









brazomyna a écrit :



Ben non, justement. Sors de tes réflexes OO-class.

(…)

Accepte de te détacher de tes ‘réflexes’ OO-class





C’est ce que j’ai lu (et que j’ai appliqué) durant mon apprentissage du JS.

&nbsp;

Maintenant peut-on encore donner ce conseil, à l’heure où toutes les surcouches de JS + (pardonne du peu) la dernière version du langage en date se dirigent précisément vers ce concept de classe qu’il faudrait oublier ?&nbsp;



J’ai lu des tonnes d’articles et d’ebooks décrivant à quel point le prototypage c’est le nirvana.

Dans les faits tout le monde tente de s’en éloigner ou de proposer une alternative, ECMAScript y compris&nbsp;<img data-src=" />









Zed-K a écrit :



C’est ce que j’ai lu (et que j’ai appliqué) durant mon apprentissage du JS.

 

Maintenant peut-on encore donner ce conseil, à l’heure où toutes les surcouches de JS + (pardonne du peu) la dernière version du langage en date se dirigent précisément vers ce concept de classe qu’il faudrait oublier ? 



J’ai lu des tonnes d’articles et d’ebooks décrivant à quel point le prototypage c’est le nirvana.

Dans les faits tout le monde tente de s’en éloigner ou de proposer une alternative, ECMAScript y compris <img data-src=" />







Voilà…



Le prototype JS est tellement cool que seuls quelques personnes arrivent à vraiment le comprendre… chacun à sa manière pour que finalement personne n’arrive à travailler en équipe <img data-src=" />



Quand on voit comme les navigateurs galèrent et doivent implémenter des optimisations de partout pour pouvoir faire fonctionner JS, il est normal de penser que JS est mal pensé.









Zed-K a écrit :



peut-on encore donner ce conseil, à l’heure où toutes les surcouches de JS + (pardonne du peu) la dernière version du langage en date se dirigent précisément vers ce concept de classe qu’il faudrait oublier ?







D’une part, je pense que justement l’évolution dans le sens de l’OO-class n’est pas étrangère l’arrivée d’une foultitudes de gens issus du monde Java/C++/C# etc… et qui sont in-foutus de comprendre une autre approche des choses, et critiquent justement l’absence du seul truc qu’ils connaissent. Pour moi, on sacrifie un peu la cohérence à la popularité. Je dis pas que c’est prédominant, mais je suis persuadé qu’il y a une part de ça.



D’autre part, l’un et l’autre ne sont pas exclusifs. Ils sont complémentaires.





  • L’utilisation d’un paradigme OO-class propose ses propres avantages:



    * on a un typage d’objet fort, ça permet d’assurer une certaine cohérence dans une chaine de responsabilités et de code

    * ça peut (beaucoup) aider pour l’optimisation du côté du moteur d’exécution, parce que le carcan qu’il impose permet au moteur d’exécution de savoir exactement à quoi s’attendre à l’avance.





  • L’utilisation du paradigme OO-prototype propose d’autres avantages:



    * contrairement à la notion de classe qui est un type, on n’est plus dans un carcan rigide et immuable pour la durée de vie de l’objet, qui doit par ailleurs être défini en amont. Avec une approche prototype, un objet veut changer de ‘type’, de ‘prototype’, ajouter/supprimer des attributs (données, fonctions), etc … ? tout est faisable, souple même en plein runtime et au beau milieu de la durée de vie de l’objet.





    Bref, comme partout, les deux approches ont leurs points forts et leurs inconvénients. Il n’est donc pas totalement délirant de les voir co-exister , et à la limite vu que de toute façon on avait déjà avant une embryon d’OO-class dans JS qui pour le coup était merdique (cf. l’excellent (e)book de D.Crockford), autant revoir le truc pour quelque chose de plus propre.









CryoGen a écrit :



Le prototype JS est tellement cool que seuls quelques personnes arrivent à vraiment le comprendre… chacun à sa manière pour que finalement personne n’arrive à travailler en équipe <img data-src=" />





C’est un faux argument de critiquer la qualité d’un outil parce que tu peux trouver des gens qui s’en servent mal.

C’est aussi pertinent que de dire que les couteaux “caynul parce qu’il y a des gens qui s’en servent pour faire des homicides”.










Nithril a écrit :



Mon propos est plus haut niveau. Le prototype c’est la plomberie qui va permettre de mettre en place certains  principes de l’orienté object notamment l’héritage…





Ok, je comprends mieux ce que tu voulais dire.

Je parle plutôt de polymorphisme, réutilisation de code, etc… dans ces cas là, perso, pour justement différentier ces concepts ‘OO high level’ de ce qu’on appelle couramment l’héritage au sens Java/C++/etc…



Bref, une histoire de mot et de définitions personnelles, mais sur le principe on est d’accord.





Que ce soit en utilisant un principe de class ou de prototype, le besoin derrière su cet aspect est le même. Bref, c’est puissant, mais peu structurant. Typescript vient structurer tout cela.





C’est justement ce qui fait son intérêt qu’il soit peu structurant puisque ça apporte un gros gain en souplesse, notamment pendant le runtime (cf. mon post avant).












CryoGen a écrit :



Voilà…



Le prototype JS est tellement cool que seuls quelques personnes arrivent à vraiment le comprendre… chacun à sa manière pour que finalement personne n’arrive à travailler en équipe <img data-src=" />



Quand on voit comme les navigateurs galèrent et doivent implémenter des optimisations de partout pour pouvoir faire fonctionner JS, il est normal de penser que JS est mal pensé.







En fait, j’ai surtout l’impression que quand on vient de l’objet, c’est très compliqué de voir autre chose, même la programmation fonctionnelle. J’ai l’impression qu’il faut toujours réussir à tordre le truc pour retrouver de l’objet là où il n’en a pas.



Puis tu m’étonnes qu ‘il faut de l’optimisation quand tu vois ce que des gens font avec Jquery.









zefling a écrit :



En fait, j’ai surtout l’impression que quand on vient de l’objet, c’est très compliqué de voir autre chose, même la programmation fonctionnelle. J’ai l’impression qu’il faut toujours réussir à tordre le truc pour retrouver de l’objet là où il n’en a pas.





C’est ce que je voulais dire avant, mais tu l’as dit mieux que moi <img data-src=" />







zefling a écrit :



quand tu vois ce que des gens font avec Jquery.





même principe qu’avant: ce n’est pas tant la techno qui est en cause ici, mais la mauvaise utilisation qui en est faite.









brazomyna a écrit :



C’est un faux argument de critiquer la qualité d’un outil parce que tu peux trouver des gens qui s’en servent mal.

C’est aussi pertinent que de dire que les couteaux “caynul parce qu’il y a des gens qui s’en servent pour faire des homicides”.







Quand le mode d’emploi de l’outil est “demerdez-vous” , on peut critiquer.

Il est assez aisé d’apporter une définition à un “objet”, alors qu’aucun de vous n’a pu expliquer le “prototype”. Faisant du javascript (principalement avec angular 1) je me suis pas mal accroché pour piger la notion de prototypage et comment l’exploiter à peu près correctement… une recherche sur le net prouve à quel point cette notion est vague pour beaucoup de monde, d’où l’intérêt de couche comme TS ou CS.



J’ai bien conscience que je ne maitrise toujours pas la notion à 100%… mais croire que l’orientation prototype est aussi compréhensible et pratique que la notion OO alors que personne n’arrive à l’expliquer simplement, me semble hasardeux.









zefling a écrit :



Non, il ne structure rien du tout vu que tu perds totalement la notion

de prototype en TypeScript, et pour moi ça reste une sacrée perte. C’est

même vraiment relou dans certain cas et je me retrouve à faire de façon

compliqué ce que j’aurais pu faire simplement.







Typescript étant un superset de javascript, tu ne perd pas cette notion.&nbsp; prototype est une propriété existante de type any. Tu peux ecrire: FooClass.prototype.bar = () =&gt; alert(“bar”);



&nbsp;Par curiosité qu’est ce que tu essaie de faire en TS qui te demande de manipuler le prototype?



&nbsp;

&nbsp;





zefling a écrit :



En fait, j’ai surtout l’impression que quand on vient de l’objet, c’est très compliqué de voir autre chose, même la programmation fonctionnelle. J’ai l’impression qu’il faut toujours réussir à tordre le truc pour retrouver de l’objet là où il n’en a pas.



Puis tu m’étonnes qu ‘il faut de l’optimisation quand tu vois ce que des gens font avec Jquery.





Précise quand on vient d’un langage objet avec un mécanisme de class car Javascript est un langage objet.





&nbsp;









brazomyna a écrit :



Ok, je comprends mieux ce que tu voulais dire.



Je parle plutôt de polymorphisme, réutilisation de code, etc… dans

ces cas là, perso, pour justement différentier ces concepts ‘OO high

level’ de ce qu’on appelle couramment l’héritage au sens Java/C++/etc…





Bref, une histoire de mot et de définitions personnelles, mais sur le principe on est d’accord.&nbsp;





On est d’accord

&nbsp;

&nbsp;



C’est justement ce qui fait son intérêt qu’il soit peu structurant puisque ça apporte un gros gain en souplesse, notamment pendant le runtime (cf. mon post avant).



On est d’accord. Mon propos porte sur TS en tant que superset de JS. Pas de JS tout seul.&nbsp;&nbsp;&nbsp;&nbsp;



Ouais JS c’est le bordel, après quelques années à devoir m’en farcir ci et là j’en suis venu à des choses simple



1/ Osef d’essayer de comprendre exactement la notion de prototype, de toute façon les concepteurs de Js ne savent eux même pas vraiment ce que ça c’est …

2/ Arrêter d’utiliser des notations chelou pour faire des classes autant utiliser le prototype (le machin fourre tout chelou)

3/ Surtout serrer les fesses parce que Js est implémenté de façon What’s The Fuck dans chaque navigateur



En gros pour faire de la Poo faire simple pour une classe Toto :



function Toto(machintruc1, bidule2) &nbsp;{

&nbsp;&nbsp; this.machin = machintruc1;

&nbsp;&nbsp; this.bidule = bidule2;

}



Toto.prototype.Affiche = function(ouinouin) {

&nbsp;&nbsp;&nbsp;&nbsp; alert(this.machin.value() + “_” + this.bidule.what() + “_” + ouinouin);

};

&nbsp;








gogo77 a écrit :











&gt; C’est qui les “autres”? On peut leur faire confiance?



Syndrome NIH. Tu checks les CV des auteurs des 150 outils/libs que tu utilises ? Tu peux auditer le code sur github si besoin.





&gt; et bien sûr il y a les TSD pour toutes les versions des librairies



Les grosses libs sont correctement maintenus. Si une lib n’a pas de tsd tu peux simplement omettre les annotations lors des appels à celle-ci.





&gt; t’as vraiment cru que c’était comparable?



tsc - TypeScript compiler. Si tu n’as pas confiance dans le principe derrière tsc alors tu n’as pas confiance en GCC.





&gt; C’est quoi mieux?



Les avantages du typage statique, besoin de détailler ?





&gt; c’est pas insurmontable de connaître TS tout en restant à jour côté JS



Je vois pas comment tu peux faire autrement : TypeScript est un superset de JS…





&gt; TS propose une syntaxe simple aujourd’hui […] les divergences seront peut êtres plus importantes qu’aujourd’hui



Ta crainte est infondée. TypeScript = JavaScript + typage statique. Le but n’est pas de créer un nouveau langage (Dart par exemple).





&gt; Si le fait d’ajouter une couche à ton environnement de dev ne te fais pas sourciller



Si mais pas pour les fausses raisons que tu cites par méconnaissance.

Gros inconvénient : TypeScript impose une chaîne de compilation complexe (gulp, grunt…) de la meme façon qu’utiliser Babel.









Nithril a écrit :



Typescript étant un superset de javascript, tu ne perd pas cette notion.  prototype est une propriété existante de type any. Tu peux ecrire: FooClass.prototype.bar = () =&gt; alert(“bar”);



 Par curiosité qu’est ce que tu essaie de faire en TS qui te demande de manipuler le prototype?







J’essayais détendre un truc de Material2, et je n’y suis pas arrivé, du coup je suis passé par un truc foireux, mais j’avais vu nul part ça. Je testerais lundi. <img data-src=" />









Nithril a écrit :



Précise quand on vient d’un langage objet avec un mécanisme de class car Javascript est un langage objet.







Un exemple comme ça :

http://sebastien-dupire.info/faire-de-la-poo-avec-javascript.html



Je suis désolé, mais parmi mes collègues, je pense qu’il y en a que 2 ou 3 qui savent vraiment se servir des prototypes. Là, on est parti sur TS pour un nouveau projet (j’ai pas choisi la techno), et certains veulent encore faire comme si c’était du Java. Non ! Non !!









tanguy_k a écrit :



Gros inconvénient : TypeScript impose une chaîne de compilation complexe (gulp, grunt…) de la meme façon qu’utiliser Babel.





Sur ce point là en particulier je te rejoins.









zefling a écrit :



J’essayais détendre un truc de Material2, et je n’y suis pas arrivé, du coup je suis passé par un truc foireux, mais j’avais vu nul part ça. Je testerais lundi. <img data-src=" />







Tu peux partir du principe qu’un code qui fonctionne en JS ,&nbsp; fonctionnera également en TS.



&nbsp;









Nithril a écrit :



Tu peux partir du principe qu’un code qui fonctionne en JS ,  fonctionnera également en TS.







Par contre, il ne compilera pas forcement. <img data-src=" />



TS reste vraiment pratique, que ce soit pour de petits projets projets ou d’autres plus grands.

En terme de lisibilité du code y a pas photo, quand bien même on garde son code JS bien organisé et propre. Perso je m’y retrouve beaucoup plus facilement, et il est plus simple d’avoir un dev quasi proche de la POO avec Typescript qu’avec du JS pur (ou là on part sur du prototypage qui peut vite prendre la tête).



Sans compter que le code généré est particulièrement propre (pour une fois), qu’il nous fournit un typage (quoi que pas assez fort à mon goût), les signatures de fonctions, etc.



Depuis que je l’utilise j’ai vraiment du mal parfois à revenir sur du JS natif, qui reste quand même un gros foutoir ce qui s’explique par l’historique du langage M.ême si ça commence à aller mieux depuis ES6 et surtout ES7, mais tout n’est pas encore pris en charge par les navigateurs… ce que comble en partie TS.








Berbe a écrit :



Tout à fait d’accord : ce néologisme est un sous-ensemble de “compiler” en ne faisant qu’ajouter des conditions sur l’objet de destination.

TypeScript compile en JavaScript car on passe d’un langage à un autre. Point.





A titre personnel, compiler = traduire en langage machine (processeur).

interpréter et ce nouveau terme que je découvre (on aurait pu utiliser traduire…) décrivent deux réalités bien différentes de compiler, n’en déplaise à certains bidouilleurs qui s’en sortent peut-être mieux que d’autres dans la confusion mais n’iront pas très loin en général quant à leurs devs…









brazomyna a écrit :



Je ne peux que plussoyer: malheureusement beaucoup n’ont pas vraiment compris qu’une bonne partie de la puissance du JS repose sur l’“orienté prototype” qui n’est pas de “l’orienté objet” comme les autres.





Comme l’on dit d’autres, c’est vachement dur de comprendre l’intérêt de l’orienté prototype par rapport à l’orienté objet classique.

J’ai essayé de toute bonne foi, mais j’ai pas réussi.









Zerdligham a écrit :



Comme l’on dit d’autres, c’est vachement dur de comprendre l’intérêt de l’orienté prototype par rapport à l’orienté objet classique.

J’ai essayé de toute bonne foi, mais j’ai pas réussi.







En très caricatural:



L’approche ‘OO classique’ t’impose des contraintes en terme de typage pour les classes d’objets, qui définit de façon stricte: 1- la nature d’un objet, de sa naissance à sa mort ; 2- les entrées/sorties de fonctions.



L’approche ‘OO prototypal’ a une approche différente, ou il n’existe plus vraiment de ‘type’ strict d’objet (au sens technique du terme. Ca a:



1- beaucoup d’avantages en terme de souplesses et de liberté d’écriture de code. Cette souplesse apporte énormément d’efficience dans l’écriture du code … pour qui s’en sert à bon escient. Evidemment - c’est comme tout, si c’est utilisé à mauvais escient par un dev abruti, non rigoureux, ou que l’organisation du projet ne suit pas pour définir des bonnes pratiques, ça fait des horreurs en terme de qualité et de maintenabilité (*).



2- un avantage incomparable en terme de souplesse au moment du runtime, un objet n’ayant pas de type déterminé de sa naissance à sa mort comme avec des classes, il peut en changer, muter, être augmenté/affiné, jouer le rôle d’union, … Son ‘type’ est juste ce qui le compose concrètement à un instant t



3- des désavantages en termes de capacité d’optimisation par le moteur d’exécution: plus de souplesse = comportement à priori moins prévisible par l’environnement d’exécution, qui peut donc appliquer moins d’optimisations ‘agressives’ en amont.



(*) Mais c’est pas l’outil le problème dans ces cas là, comme c’est pourtant souvent bêtement reproché. Il ne viendrait pourtant à personne l’idée de reprocher pas l’existence des pointeurs en C, et pourtant on peut là-aussi faire des horreurs avec.



Un article complet sur les problèmes de transpiration des développeurs…



Franchement, NI Team, vous nous aviez habitué à mieux …



<img data-src=" />


C’est vrai, ils n’ont même pas parlé les risques des sels d’aluminium dans les déodorants. Et quand on parle de transpiration, c’est important d’aborder ce sujet.


Tout ce qui est dériver vite fait des objets pour en adapter marginalement le comportement (ou faire des unions) se fait aisément en héritage classique , et même si c’est un peu plus verbeux, avec un IDE décent, ça se fait en quelques clics.

Là où il y a une vraie différence c’est si on commence à avoir des objets qui ont un comportement ‘non prévisible’ au runtime (par non prévisible, j’entends bien sûr, ‘il n’y a pas moyen d’imaginer ce comportement au moment du développement’, puisque sinon, avec les interfaces Java ou équivalent, ça se règle facilement), ou qui mutent dans tous les sens au runtime.

Seulement j’ai jamais rencontré une telle situation, ni même réussi à en imaginer une.



J’aime bien le javascript, mais je m’y perds moi-même très vite dans mes propres développements <img data-src=" />

Après je ne suis dev ni de métier ni de formation, ça n’aide certainement pas à avoir une bonne vision des avantages et inconvénients des différents modèles, ou a avoir les méthodes qui permettent d’utiliser les différents modèles proprement.








Zerdligham a écrit :



Tout ce qui est dériver vite fait des objets pour en adapter marginalement le comportement (ou faire des unions) se fait aisément en héritage classique , et même si c’est un peu plus verbeux, avec un IDE décent, ça se fait en quelques clics.







Evidemment qu’on pourrait techniquement faire la même chose qu’en JS avec tel ou tel autre langage ; l’atout ne concerne pas une capacité technique que seul JS aurait, mais d’efficicence.



Typiquement, c’est pas ‘un peu plus verbeux’:




  • c’est beaucoup plus formel, long à faire et complexe.

  • ça ne supporte pas l’ajout facile d’un trait à une classe existante qui a déjà sa propre hiérarchie de type.

  • ça ne supporte pas cette même notion qui évolue en runtime

  • ça ne supporte pas l’inclusion de traits non directements définis dans le projet sans devoir relier à un projet tiers (notion de linking, d’en-têtes, etc…)



    dans un cadre ou la donnée est centrale, où son contenu peut être amené à varier, où l’application n’est pas un tout monolithique en soi, et donc typiquement lorsqu’on parle d’applications qui intéragissent fortement avec d’autres entités, notamment en réseau, ça apporte beaucoup de souplesse, de simplicité et d’efficience.