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).

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 " />







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.

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.

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.

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.
  
  
  

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 ³⁄₄ des fonctionnalités du langage. J’imagine que si je ramène ma bibliothèque de sérialisation qui repose que sur des template<>, 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.

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, " /> pour les koalas.

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.

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.