Où va-t-on avec JavaScript ?

Je pense que ça n'a pas de sens.

Un des principaux avantage de JS est de pouvoir dynamiquement faire évoluer ses objets.
Ajouter supprimer remplacer des méthodes et des membres.

si vous passez au typage fort (contraint) pour rendre ce genre de chose utile

Code:

---

1 2 3 4 5 6 7

var fct;   fct = function fct(value) { if (!(value instanceof Type)) { throw new Error('value must be an instance of Type'); } };

---

alors vous perdez cette fonctionnalité essentielle de javascript. car à quoi va vous servir de savoir que value est une instance de Type si l'objet a perdu ses membres.
Si vous voulez pouvoir faire ça il est obligatoire que le langage interdise l'ajout/suppression/modification de membres ou de méthodes.

Vous vous retrouvez alors comme avec les autres langages à base de class Statiques à devoir multiplier le code pour faire des choses très simples en JS.

Je sais qu'on m'a mis sur le dos une étiquette anti classe statique. Il n'en est rien. J'utilise quotidiennement ces concepts.
si vous représentez une personne dans votre système par une instance, les capacités de votre "objet" devraient suivre l'évolution de la dite personne. or un bébé n'a pas les mêmes caractéristiques qu'un vieillard.
Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado. De plus la transition est progressive, elle n'est pas la même pour tous les individus.

JS est un langage qui permet de faire vivre ces objets en les faisant évoluer, chose que ne permet pas les langages avec un typage contraint et statique.

Je ne juge pas l'un ou l'autre je pense simplement que les domaines d'application sont différents bien qu'il y ait des zones de recouvrement. Vouloir contraindre JS à devenir un langage à typage contraint et statique c'est signer son arrêt de mort. Il n'aurait alors rien à apporter. Il existe déjà beaucoup de langages dans ce domaine.

Je pense par contre qu'il a la place pour d'autre langage embarqué dans le navigateur.
La norme HTML le prévoyait et il y a eu vb par exemple dans IE.
Il manque donc juste aujourd'hui un consensus pour adopter un langage de ce type dans le navigateur à côté de JS.

A+JYT

Citation:

---

Envoyé par sekaijin

Je pense par contre qu'il a la place pour d'autre langage embarqué dans le navigateur.
La norme HTML le prévoyait et il y a eu vb par exemple dans IE.
Il manque donc juste aujourd'hui un consensus pour adopter un langage de ce type dans le navigateur à côté de JS.

---

Oui. Dans les temps anciens, Java accompagnait Javascript.

Alors la question est : que penser des préprocesseurs tel que TypeScript ?
J'ai lu que ces pseudos-langages avaient comme vocation d'ouvrir le chemin vers cet "autre langage embarqué" dont vous parlez.

va ton dans ce genre de demande http://www.developpez.net/forums/d14...framework-js/?

je ne pense pas
mais en entreprise des chose comme
sonatype
ne sont pas rares en entreprise

A+JYT

Citation:

---

Envoyé par ascito

je ne pense pas

---

Désolé, je voudrais une précision.
Vous répondez à la question d'Ascito ou à la mienne ?

Citation:

---

Envoyé par ascito

va ton dans ce genre de demande http://www.developpez.net/forums/d14...framework-js/?

---

Non, je vous remercie infiniment de votre sollicitude, mais je ne me pose aucune question quant aux outils que je dois utiliser. Je programme en Javascript (Mais j'utilise aussi le C, Java, assembleur... quand j'en ai besoin. J'ai même programmé en Pascal ;) )
Je pose la question au sujet de TypeScript car il est commandité par un acteur majeur de l'informatique et risque de s'imposer dans les normes futures du Javascript (je suppose donc que cette question correspond au sujet)

Le Javascript est très complet et me satisfait parfaitement. Le javascript est un langage qui possède des propriétés très intéressantes.
Notamment l'absence de typage, qui n'est peut-être pas un oubli, mais la volonté de proposer un autre format de programmation que celui qui était répandu dans les années 80.

Je regarde avec circonspection l'auteur du langage Pascal (qui était le fer de lance des langage 'typé' des années 80) manipuler du javascript.
Je ne remet pas en cause l'idée de créer une passerelle entre Javascript et un langage typé dans le HTML5.

Je voudrais connaître les avis des autres utilisateurs de Javascript au sujet de cette idée de passerelle, et de la façon dont elle est mise en oeuvre.

je répondais @Ascito

Pour moi typage statique et typage dynamique sont complémentaire.
Et si je regarde les évolutions des langages il n'y a pas grand-chose de neuf depuis bien longtemps.

Les langages à typage statique fort embarquent de plus en plus de techno pour les rendre plus dynamique ou collaborer avec des langages plus dynamiques. Et les langages dynamiques fleurettent avec les typages statiques.

Mais ce n'est pas nouveau. TCL qui a eu son heure de gloire (il y a 20 ans et est toujours utilisé) est un langage Dynamique qui s'associe très facilement avec C/C++
Aujourd'hui on voit apparaitre exactement la même association avec le couple Java/Ecmascript (nashorn dans java 8)

Javascript s'inscrit directement dans cette approche. le langage (EcmaScript) fourni l'isfrastructure d'exécution et l'hôte fourni tout le reste. Dans le navigateur chaque appel à une méthode du navigateur crée ou invoque un objet développé avec un langage natif (généralement C++)

Ce genre de besoin correspond à tous les langages de macro embarqués dans les Applications. Un langage interprété souple et concis associé à des objets natif.
Ce qui est moins courant c'est l'approche de Rhino/Nashorn ou le langage embarqué à accès à toutes les classes du langage Hôte et non plus seulement quelques objets prédéfinis.

Javascript arrive à un seuil. il a été définit pour faire quelques amélioration dans un page web (après sa naissance côté serveur) mais il sert de plus en plus à écrire de véritables application. J’ai déjà vécu ce phénomène avec les Shell Scripts. À une certaine époque bon nombre d'acteur ont commencé à utiliser sh comme langage de programmation pour faire de vrais appli et non plus seulement pour scripter quelques commandes. Cette approche c'est heuré au même problème que JS rencontre. À savoir le typage dynamique pour l'essentiel. Lorsque le développement de l'application prend de l'ampleur cela pose des difficultés. Et on a alors vu apparaitre des langages interprétés typé de façon plus statique pour répondre à ce besoin. On a vu aussi beaucoup d'acteur revenir vers des langages plus durs. Mais se posait alors d’autres difficultés comme la perte de souplesse pour certaines parties. Et c'est à ce moment-là que des langages dynamiques embarqué ont pris du poids.

L'association de langage strict avec de langages plus souple est aussi vieille que l'informatique. LISP n'est quasiment jamais utilisé seul par exemple.

A+JYT

Citation:

---

Envoyé par sekaijin

le langage (EcmaScript) fourni l'isfrastructure d'exécution et l'hôte fourni tout le reste.

---

C'est précisément au sujet cette partie que je m'interroge.

Au sujet de l'interpréteur
Quel impacte l'interprétation des léxèmes peut-il avoir sur le déroulement d'un script ?
Ce traitement, qui peut être parfois inutile, est-il contournable ?
(par exemple avec des portions compilées, à l'image des macros l'assembleur dans un script en C)

Est-ce que l'EcmaScript est destiné à rester la seule norme de langage dans l'environnement HTML ?

Pour se passer d'un interprète il faudrait que toutes les machines tous les navigateurs utilisent le même code binaire.

À défaut et on le voit bien avec les applications de nos machine il faut créer autant de version que d'OS et de processeurs.
Il devient vite évident que l'intérêt du navigateur est alors plus que douteuse.
À quoi peut bien servir un client web quasi universel si on doit fournir autant de contenu que d'OS possible ?

Reste donc l'approche de la machine virtuelle. Ce qui était le but de Java à l'origine. On compile dans un code intermédiaire reste à la VM de faire le reste.
Là encore on voit bien que ce n'est pas toujours aussi simple.

À cela s'ajoute le contexte. On n'est pas dans un cadre où l'in doit exécuter des applis dont le code fait du calcul intensif avec des temps de réponse contraints et fort.
Une webapp se doit d'être réactive à l'échelle humaine de temps. Le calcul intensif, les traitements lours c'est pour le serveur. Le poste client doit lui assurer une bonne présentation et de l'a réactivité aux actions de l'utilisateur.

La question à se poser est quel est l'impact de l'interprétation dans ce contexte. En tenant compte du fonctionnement de l'interprète. Aujourd’hui le parsing du code est infime en rapport du temps réseau. Ensuite le moteur JS compile le code à la volée et conserve la version compilé durant toute la vie de la session. Du coup soit on a une application qui est multi page et qui génère du js dynamiques sur le serveur et le navigateur ne peux mettre ce code source en cache et encore moi conserver la version compilé. Soit on a une application mono page avec tous le js dans des fichiers statique et le moteur peut utiliser le cache réseau et surtout le code compilé. Entre ces deux approches extrêmes je vous laisse imaginer toute les possibilités.
Toujours est-il que si on se met dans la cadre idéal le temps de compilation devient marginal. Le moteur exécutant le plus souvent du code déjà compilé. Et plus on utilise l'appli plus ce temps se marginalise.
Si on se met dans le pire des cas. Il est déjà difficile pour un humain de percevoir le pouillème de temps que représente la compilation dans l'exécution d'un code.
Aujourd'hui les moteur JS ne fonctionnement pas sur le principe du ByteCode. ils utilisent des compilateur JIT qui produisent du code natif.

Dans le cadre d'ihm web, JS est largement assez performant pour ne pas avoir à se poser des questions de compilation ou pas. Mais aujourd'hui de nouveaux usages du navigateur apparaissent et entre autre l'utilisation de rendu 3D de jeux et bien d'autre chose. Là on commence à effectivement se retrouver avec du calcul plus intensif coté client. Et se pose réellement le problème des performances pures. Ce qu'il faut comprendre c'est que passer du compilé à la volé au précompilé c'est gratter des ns ici ou là.

Si je reprends les développements d'appli en shell. Aujourd’hui on ne se pose pas la question on fait du traitement lourd en C++ et on réserve le shell à l'adaptation à l'OS.
Tout script sh peut être refait en C ou C++ il va gagner en perf.
Mais quel gaint réel pour l'utilisateur ? Quelle complexité de dev ajoutée pour les développeurs ?

JavaScript est compilé. Perdre cette capacité à s'exécuter "partout" cette facilité de mise en œuvre pour des nanosecondes, est-ce réellement un gain ?

Mais on voit bien avec WebGL et tout un tas d’autres technos que les besoins s'étoffent.

A+JYT

Toutes ces explications sont très instructive (car très didactique 8-) ). Elles offrent un résumé intéressant de la situation actuelle, des orientations et des nouvelles contraintes qui émergent dans l'environnement HTML.

Vos messages successifs permettent de préciser la situation. Et surtout la diversité des domaines abordés esquisse un plan d'ensemble cohérent; tout en conservant à l'esprit qu'il ne s'agit que d'exemples pour cet univers très riche.

Vous m'avez conforté dans l'idée de continuer à travailler avec Javascript, mais je reste en éveil ;)

Merci pour ces éclaircissements

Citation:

---

Envoyé par sekaijin

Si vous représentez une personne dans votre système par une instance, les capacités de votre "objet" devraient suivre l'évolution de la dite personne. or un bébé n'a pas les mêmes caractéristiques qu'un vieillard.
Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado. De plus la transition est progressive, elle n'est pas la même pour tous les individus.

---

Tu fais comme si avec les lagunages à typage static on est bloqué pour pouvoir réaliser un truc pareil à évolution progressif, et tu mélange entre avoir un type static pour représenter une catégorie de personne une une fois déjà sérialisé et qu'on veut le dé-sérialiser pour lui donner une nouvelle catégorie. Avec l'héritage, on a toujours la même personne mais étendu.

N'oublies pas que dans la vie courante on a des hommes et des objets concrets, on les vois, on a pas des variables qui les représentent, Le plus important pour la personne c'est son identité, tu es né ton acte de naissance reste le même, et il y a un ensemble de propriété qui sont connus en commun(taille, age, poids...).

Quand je dois utiliser des variables(fiche à remplir pour le passage du concours de permis, le bac ou l'inscription à l'université) certes c'est la fiche qui me définit, c'est comme une variable et là on doit définir le contexte et les champs à remplir sont connus.

Tout ce qui va évoluer passe par des listes(tes modules sur lesquels tu es inscrit, tes notes, ou la liste de tes délits dans ton casier judiciaire), venir définir un attribut à chaque inscription à un module serait du bordel.

Ainsi, si au préalable je sais que mon programme va évoluer continuellement et que au cours du même programme je dois faire évoluer mes objets je n'ai pas qu'une seule technique avec les langages à typage static.

Si je suis incapable de connaître la liste des attributs comme j'ai dis j'opte pour une liste dynamique d'objet/générique, sinon pour mieux faire j'utilise un map, qui me permet d'associer le nom de l'attribut avec la valeur.

Et c'est l'objet lui même qui nous informe sur ses attributs dynamiques, je ne crée pas de nouveaux objet.

Le problème avec ton cas en javascript, j'ai un type unique, donc si je viens consulter ton programme et je veux travailler je ne peux pas savoir qui sont les vieux et les ado, et je ne peux pas me permettre de demander un attribut que je en connais pas. Il faut consulter objet par objet jusqu'à se perdre par ce qu'on cherche la personne qui a des barbes :aie:

Avec les langages à typage static en POO, j'ai aussi une technique plus intéressante si je veux toujours garder la même personne en mémoire mais ajouter des attributs, sans utiliser des listes, alors j'utilise patron de conception nommé Décorateur, à chaque fois je décore la même personne, avec des attributs et des méthodes.

Le principe est simple pour celui qui veut le savoir : j'ai un objet possible d'être décoré et un objet décorateur alors tous les deux vont hériter d'un objet nommé composant et le décorateur aussi déclare un attribut de type composant en son interne. Donc si je crée un décorateur il prend un objet de type composant(donc un décoré), je peux déclaré autant de type de décoration qui vont hériter de décorateur, donc si b décore a, donc b reçoit a dans son constructeur, et j'ai un c qui veut décorer a, donc c reçoit b dans son constructeur car b aussi est un composant, et on peut enchaîner et on utilise des technique de récursivité dans les méthodes.

Quand tu deviens ingénieur tu est diplômé ou expert confirmé senior, donc je te décore et je peux aussi connaître les personne ingénieur, les experts et les personne normales, au moins je connais mes décorations. Tu as reçu un trophée de developpez.com par ce qu'on a déjà défini c'est quoi le trophée donc un type de décoration défini. Et ce n'est pas un attribut propre à toi.

Mais en js tu veux que le trophée soit un attribut propre à toi

Citation:

---

Tu fais comme si avec les lagunages à typage static on est bloqué pour pouvoir réaliser un truc pareil à évolution progressif

---

Je n'ai jamais dis qu'avec les typage statique il n'y avait pas de solutions

je dis que le typage dynamique, et la possibilité de changer dynamiquement un objet n'existe pas avec les typage statique et que donc il faut pour cela trouver des moyens pour représenter un objet évolutif ce qui en javascript s'écrit naturellement.

je dis que dire que cette capacité est une tare est une erreur. c'est une force.

et Je n'ai jamais dis que le typage statique n'était pas bien.
j'ai dis que le typage dynamique offre une souplesse que le typage staique n'offre pas. au même titre que le typage statique offre des services que le typage dynamique n'offre pas.



A+JYT

Oui je suis d’accord dans la souplesse pour réaliser ce qu'on veut dans ce sens. Mais dire que c'est une force non, c'est du bidouillage, au prealable js n'a pas été fait pour de grosses programmes, du coup on bidouille et on souffre pour ça après, alors où est la force.

Comment dire que c'est une force alors que ça ouvre aux développeurs la porte de pondre du code qui n'est pas forcement réutilisable, du code que seul celui qui l'a codé le comprenne.

Ceux qui ont pensés aux langages à typage static non seulement ils se sont inspirés de ce qui passe dans la vraie vie, mais ils ont pensés que pour pouvoir avoir quelque chose de mieux simple à utiliser plus structuré, pour le present et pour le future il faut de la patience.

Ce n'est pas par ce que Mercedes-Benz a déployé plus d'effort et temps pour implanter ses usines et utiliser plus de ressources que Renault qui utilise moins est mieux, possible que le temps qu'il passe pour pondre un véhicule est moins que le temps que Mercedes Benz passe.

Bac+2, on développe déjà et Bac+3, on code encore mieux, Bace+5 on est ingénieur. Pour une bonne chose il faut faire mieux et un peu de patience.

Toi tu veux dire à quoi ça sert un Bac+5 pour un simple développeur alors qu'avec un bac plus 2 je peux coder, donc plus de souplesse non? Pour moi js est comparé à une formation de bac+2 point barre.

Pour faire des choses extraordinaires il faut encore percé dans des langages plus robustes qui permettent non seulement de faire des choses que js ne peut jamais faire(compilateur, manipulation de bit, multitâche,programmation fonctionnelle...) mas des programmes bien structurés et plus robustes pour une longue durée et réutilisables facilement, c'est pour cela qu'il faut de la rigueur dans la programmation, on peut pas tolérer des bêtises, si tu veux du sérieux bienvenue, si tu as peur de la rigueur au détriment de quelque chose plus robuste alors vas y dans javascript

Le concept même de ce dynamisme sur les objets est contre nature même. Quand on fait des choses on doit les faire comme dans le monde naturel, quand un PC portable sort de l'usine il reste lui même, il est hors de question à ce que je pense lui ajouter un 2e écran, ou plus de RAM au dessus des places qui sont définis pour les barres de RAM. Quand on veut implanter un organe manquant à un homme ça nécessite une opération de chirurgie plus complexe.

Javascipt veut que sur des objets sortie de l'usine on ajoute ce qu'on veut, modifier les API de tout le monde comme je veux, c'est du vol ça.

Ou bien dire au prealable, ça ne sort pas de l'usine déjà fait, juste je le crée sans connaître ces composants de temps à autre je vais ajouter ce que je veux et les fonctionnalités que je veux et enfin tu as un objet que seul toi qui le comprend, non réparable s'il tombe en panne.

Un objet en js (je m'excuse tu terme) je le compare une p*t qui n'a pas de mec spécifique à chaque fois il a un nouveau mec, donc plusieurs à la fois il doit définir un nouveau partenaire et garder ses cordonnées .

sekaijin tu es expert dans le domaine et très ancien que moi, et tu sais parfaitement que si JavaScript était un langage compilé pour faire des applications bureau par exemple il serait le langage le plus vulnérable.

Sécuriser son application serait la chose la plus complexe, voir impossible il faudrait repenser même le langage.

Faire planter un programme javascipt ou le hacker est vraiment un jeu.

Un objet en javascipt est très souple que sa vie est même mis en danger. Je crois que la comparaison que j'ai fais est mieux que le vrai cas d'un objet javascript.

Un objet en JavaScript accepte à ce qu'il soit violé par tout le monde, il est content il ne dit rien, pas de concept d'encapsulation, rien n'est privé, même si je lui enlève des attributs qui définissent son existence il ne dit rien, donc je peux lui enlever son cœur et son cerveau :alerte: c'est grave!!! :aie:

Mais vous me prêtez des intentions que je n'ai pas.

Je vais clore la discussion.
Les procès d'intention ne mènent jamais à rien.

Le fait que les langages à typage statique incluent de plus en plus de dynamismes et très probablement une grossière erreur que font tous les ingénieurs qui travaillent à l'évolution et l'élaboration de nouveaux langages.
Vu que le dynamisme est selon vos dires une catastrophe.

Les chercheurs et les scientifiques qui utilisent des langages interprétés pour leurs caractéristiques sont aussi des gens qui sont dans l'erreur et il faut absolument les ramener dans le droit chemin en supprimant les hérésies des langages qui ne sont pas dans la sacro-sainte norme enseignée comme étant le Saint-Graal à savoir les langages à typage statique à base de classe.

Il est clair qu'il faut aller dans le sens de la pensée unique et ne surtout pas voir une force dans les caractéristiques d'un langage s'il s'écarte de la façon normalisée de penser.

Je comprends qu'en agissant ainsi je suis entré dans une hérésie et que le monde de l'informatique va bientôt arrêter d'ajouter certaines de ces caractéristiques dans les langages à base de classes statiques.

Je comprends que l'arrivée de Nashorn est une erreur monumentale de tous les ingénieurs de la planète qui oeuvre à faire évoluer Java.

Je comprends que hors de la conception standardisée. Point de salut.
Je comprends que les chercheurs en informatiques qui pondent et utilisent des langages dynamiques se sont tous fourvoyés depuis des décennies.

Je vais continuer à utiliser les langages à typage statiques pour leurs forces dans les domaines où cela est une réponse pertinente à mes besoins.
Je continuerais à être dans l'erreur monumentale en utilisant les caractéristiques des langages dynamiques pour mes besoins quand ces caractéristiques sont des réponses efficaces à mes besoins.

Et je vais arrêter de vous dire que les deux approches ont des forces et des faiblesses et que ni l'une ni l'autre n'est supérieure. Je vais arrêter de dire qu’elles répondent à des besoins différents. Et je vais arrêter de dire qu'utiliser une de ces approches dans un domaine qui n'est pas le sien est une erreur de mon point de vue.
Je vais arrêter de dire que ce que propose facilement une des deux approches est difficile dans l'autre et vice-versa.

J'ai bien compris que EcmaScript est un langage pourri bon à jeter qu'il ne faut surtout pas l'utiliser pour ce qu'il sait faire. Et qu'il vaut beaucoup mieux produire des architectures complexes à base de langage statique en utilisant des conceptions normalisées, et ce même si cela n'est pas une réponse efficace au besoin.

Je vais m'empresser de dire à tous les ingénieurs système qu'il faut qu'ils arrêtent d'utiliser les Shell script et utilisent au plus vite leur compilateur C/C++ pour leur besoin. Qu'ils sont tous depuis les années 50 dans l'erreur la plus monumentale ! Parce qu’utiliser le Shell script pour faire une application de bureau implique de trop gros problèmes, ils ne doivent surtout pas l'utiliser dans leur domaine où ça répond parfaitement à leur besoin.

Alors je le dis une dernière fois. Les deux approches ont leurs forces et leurs faiblesses, les deux approches ont des domaines de prédilection. Et juger une caractéristique de l'un en se plaçant dans le domaine de l'autre n'en fait pas une mauvaise approche.

J'espère que pour une fois on lira ce que je dis et non ce qu'on veut me faire dire.
Je me refuse à dire que les langages à base de classe statiques sont de mauvais langages.
Je me refuse à dire que ces langages n'offrent pas de solutions.

Ceci sera ma dernière intervention sur le sujet. Car il est clair, que la réponse à la question
Où va-t-on avec JavaScript ?
est
On doit le faire disparaitre au plus vite.


A+JYT

Il faut bien comprendre mon but et ne déduit pas de mon message ce que je n'ai pas dis. Mon message n'a rien n'avoir avec l'abadon de Javascript ni la suppression des languages interpreté ou dynamiques. 8O

En premier lieu tu as apporté un concept de comparaison comme quoi javascript est le mieux adapté pour se conformer au monde réel, et ben je t'ai dis que non, et je t'ai montré qu'au contraire un objet dans le monde réel est quelque chose de static.

En 2e lieu tu défends comme quoi le concept de dynamisme sur les objets en javascript est une force au lieu de le réduire en une simple souplesse, eh ben saches qu'on code tous en javascript et on sait que cela ne sert que sur le gain en productivité et ça s’arrête là. Alors n'avances pas ce qui est le contraire car si on veut regarder au fond des choses, tu veux transformer une faiblesse en force.

Citation:

---

Envoyé par sekaijin

Le fait que les langages à typage statique incluent de plus en plus de dynamismes et très probablement une grossière erreur que font tous les ingénieurs qui travaillent à l'évolution et l'élaboration de nouveaux langages.
Vu que le dynamisme est selon vos dires une catastrophe.

---

Tu mélanges entre typage dynamique des variables, dynamisme grâces aux expression lambda, réflexion... d'un côté et le dynamisme sur les objet grâce au prototypage de l'autre côté :weird:, c'est ça le sujet, il faut bien lire ce que j'ai écris, voci mon message intégral

Citation:

---

Envoyé par la.lune

Le concept même de ce dynamisme sur les objets est contre nature .

---

PHP, Python, Ruby, sont des langages à typage dynamique mais pour ce qui est des objets ils sont basés sur des classes, c'est la logique d'un objet, ça sous entend déjà quelque chose bien défini Il est hors de question sur ces langages à ce que j'enlève un attribut ou que je lise un attribut privé ou protégé là où je ne peux pas, et les objets sont bien sûr stockés sur des variables.

Citation:

---

Envoyé par sekaijin

Les chercheurs et les scientifiques qui utilisent des langages interprétés pour leurs caractéristiques sont aussi des gens qui sont dans l'erreur et il faut absolument les ramener dans le droit chemin ....

---

Qui t'a dis qu'ils sont dans l'erreur, on t'as dis que tout simplement que si le besoin de typage satatic basé sur des classe se presente c'est pour des besoins de programmes bien structiré robustes, maintenables et sécurisé, et extensibles, donc si tu veux reduire l'effort pour le bsoin en une faiblesse c'est passer à coté de la plaque. Et si des scientifiques utilisent des languages pareils sache bien que leur applis ne sont pas destinés au grand public, aucun risque.

Et c'est que tu présente c'est un cas vraiment rare les rechercheurs et scientifiques cherchent des langages compilés, pour des raison de performance, et multitâche, alors ceux là que tu cite sont loins des gens qui font des programmes parallèles et qui ont besoin aussi aux supercalculateurs.

Citation:

---

Envoyé par sekaijin

Il est clair qu'il faut aller dans le sens de la pensée unique et ne surtout pas voir une force dans les caractéristiques d'un langage s'il s'écarte de la façon normalisée de penser.
Je comprends qu'en agissant ainsi je suis entré dans une hérésie et que le monde de l'informatique va bientôt arrêter d'ajouter certaines de ces caractéristiques dans les langages à base de classes statiques.

---

Pensée unique non, mais pas transformer une faiblesse en force, cadrons les chose tels qu'ils sont et ouvrons un peu les yeux, définissons les choses avec les bon termes.

Les programmes géantes qui sont devants nous sont codés avec des languges à typage static qu'ils soient objet ou non: nos OS, nos compilateurs, nos navigateurs, nos machine virtuelles....

Tu oses accuser ces lagunages de faiblesse par ce qu'ils n'ajoutent pas la notion de prototypage et que javascript est le plus fort avec ça? Quel troll ça!! Vraiment le monde à l'envers.

Ceux là qui ont même conçu javascript depuis 1995 (javascrit est le fruit de Netscape et Sun actuellement sous Oracle), ils ont vu cette faiblesse tous ces années et ils attendaient sekaijin pour leur dire qu'ils avaient tort alors que c'est eux même les experts qui ont conçu ça.

Dis moi ce que je ne peux pas réaliser avec les langages à typage static basés sur des classes? Tu ne cesses de dire que chacun à ses faiblesses et ses avantages: grosse troll encore.

Montres moi la seule limite devant moi qui me bloquerait d'atteindre mon but ou me défendre d'un mal avec les langages à typage static basés sur des classes et qui embarquent des API plus matures écrites bien sûr sur ses langages? Où est la faiblesse alors?

Pour moi une faiblesse c'est de ne pas pouvoir réaliser quelque chose qu'ont veut, javascript est parmi les candidats, je peux tuer ces objets comme je veux, j'accède à tout, en tant que développeur j'aurais aimé plus de sémantique dans mes instructions, que le langage m'aide à détecter mes erreurs. J'aurais aimé que mon programme JavaScript ne soit pas piraté, ou volé car j'ai déployé tant d'effort, je ne peux pas.

Mais cela ça ne constitue pas une catastrophe, car en partie le contexte de javascript définit n'est pas fait pour certaines choses et mes codes javascript marchent très bien et j'arrive à atteindre mon besoin spécifique avec, pourquoi veux-tu toujours mélanger, que lorsqu'on discute sur ce qu'il faudrait améliorer, tu as tendance toujours à dire "Eh ne voyez pas telle fonctionnalité ce n'est pas toujours beau", ah bon tu dis ça toi alors que javascrpt si on veut le comparer on ne peut même pas comparer.

Les sucres syntaxiques et les souplesses fournis pour les développeurs, les débutants, ceux qui apprennent par bidouillage ou ceux qui viennent d'un autre monde pour ne pas casser leurs habitudes n'ont en rien sur la force d'un langage, on simplifie les choses mais ça ne veut pas dire qu'on souffre d'une faiblesse.

En quoi une tablette est plus fort qu'un PC? Est ce par ce que la tablette est plus pratique qu'un PC que ce dernier est plus fort que lui.

Citation:

---

Envoyé par sekaijin

Je comprends que l'arrivée de Nashorn est une erreur monumentale de tous les ingénieurs de la planète qui oeuvre à faire évoluer Java.

---

Ah bon, ajouter une fonctionnalité est synonyme de souffrance de faiblesse. Dans le monde actuelle il y a de l'HTML5 et du JavaScrip côté serveur et dans le monde Java on développe des applications qui ont besoin de manipuler les stands du web, javascript en particulier, comme l'IDE netbeans bien fait pour les appli web en Html5, pour bureau et mobile.
Alors pour faciliter le débogage et les testes il faut quelque chose de standard pour faciliter sont intégration sur la machine virtuelle, Nashorn n'est pas le premier.

Et tout ce que je peux craindre en sécurité, il n y a pas, car JavaScrpt est interprété par la JVM et non compilé en baytecode. Nashorn facilite l'intégration d’interprétation des codes html et javascript embarqués sur des webview en JavaFX et autre, c'est une fonctionnalité pour un besoin pas une évolution dans le sens que le langage souffre d'une limite.

Citation:

---

Envoyé par sekaijin

Je comprends que les chercheurs en informatiques qui pondent et utilisent des langages dynamiques se sont tous fourvoyés depuis des décennies.

---

On dirait que tu lises programmation dynamique en recherche scientifique et tu planques dessus les langages dynamique, ça n'a rien n'avoir. Les algorithme dynamiques n'ont rien n'avoir avec les langages, on utilise des structure de données dynamiques(liste,arbres,graphes) et on a même pas besoin vraiment de programmation orienté objet basé sur des classes. Oublions même le prototypage.

Citation:

---

J'ai bien compris que EcmaScript est un langage pourri bon à jeter qu'il ne faut surtout pas l'utiliser pour ce qu'il sait faire.

---

C'est ce que tu penses mais ça ne sort pas de ma bouche, j'étais toujours d'accord qu'il offre une souplesse et je l'utilise. Aujourd'hui même j'étais entrain de coder avec.

Citation:

---

Je vais m'empresser de dire à tous les ingénieurs système qu'il faut qu'ils arrêtent d'utiliser les Shell script et utilisent au plus vite leur compilateur C/C++ pour leur besoin.

---

Je n'ai nulle part dis qu'il faut laisser les langages de script ou dynamiques. On était entrain de parler du dynamisme sur les objets et ce qu'il présente comme faiblesse et tu veux faire que la gloire de javascript est basé sur ça et tu me ramènes Shell qui n'est même pas objet et la POO avec PowerShell de Windows sur .NET est basé sur les classes.

Citation:

---

Je me refuse à dire que les langages à base de classe statiques sont de mauvais langages.

---

Je n'ai pas aussi dis que JavaScript est le mauvais des langages, il a des faiblesses, reconnaissons les c'est tout. C'est qui permettra d'évoluer. Mon enfant qui a un caractère que je n'aime pas, je ne ne jette pas et je ne l'enterre pas, je l'aime c'est mon enfant, mais je dois lui faire améliorer le comportement.

Si tu lances des messages à troll comme quoi le prototypage montre la force de javascript devant ses occurrents, ça ne passera pas tu auras toujours des obstacles. Car si tu veux ouvrir la porte aux comparaisons alors en voulant être honnêtes avec nous même et présenter les choses dans leur réalité, il n y a même pas de comparaison, tu risques de tomer dans un gouffre car on te rappellera des choses très moches en javascript.

Quand on parle de là où on va avec JavaScript restons dans le carde de JavaScript pensons sur comment améliorer les choses quels sont les nouveautés, quels sont les projets futures pour améliorer le langage. Ne cherche pas toujours à vouloir faire des comparaison et toute personne qui lit tes messages voit comme si tu pointe le doigt sur les autres et on peut ponter sérieusement sur javascript.

Et après tu dis moi j'utilise les langages à typages static, ils sont aussi fort mas.., est ce que tu as besoin de parler de ce que à ton avis est une faiblesse quand on parle de javascrpt et essayer de mettre les mettre tours deux dans une balance pour poser des réserves après?

Et parfois tu fais un double discours quand tu as donné la comparaison et je t'ai répondu tu as trouvé un issue dans la réponse, regarde bien ce que tu as dis

Citation:

---

Avec un typage statique il faut créer de nouveaux objets à chaque fois que la personne évolue pour passer de Bébé à Enfant Ado Adulte etc.. mais la vie n'est pas ainsi. On reste toujours la même personne. Une nouvelle personne n'est pas créée quand on quitte l'enfance pour devenir un ado
.....
JS est un langage qui permet de faire vivre ces objets en les faisant évoluer, chose que ne permet pas les langages avec un typage contraint et statique.

---

Qui t'a dis qu'il faut créer de nouveaux objets", toute personne qui lit ton message comprend que ce que tu dis, il faut c'est il faut, c'est une limite et une faiblesse pour les langages à typage static de même en lisant "chose que ne permet pas", pourquoi avancer des propos ainsi, les attributs dans une map ou liste n'appartiennent pas à l'objet, ou tu ne veux pas différencier entre les attributs que je connais déjà et ce qui évolue dynamiquement.
Que ce qui ne permet pas de faire ce qu'on veut. Et puis quand je t'ai montré l'ensemble des techniques existantes tu dis que tu n'a pas dis qu'il y a de solution, ah bon au moins souligne le et puis tu ajoutes dans ton message:

Citation:

---

je dis que le typage dynamique, et la possibilité de changer dynamiquement un objet n'existe pas avec les typage statique et que donc il faut pour cela trouver des moyens pour représenter un objet évolutif ce qui en javascript s'écrit naturellement.

---

Ah bon tu as dis ça avant?? Tu l'a dis nulle part dans ton message, tu lancé le troll et tu as laissé les gens croire que les langages à typage static ont des faiblesses, tu as bien bien dis qu'il faut créer" donc obligation et contrainte=> faiblesse. Ce qui représente une affirmation purement fausse et trollesque.

Moi quand je dis qu'on ne peut pas faire ça avec javascript c'est qu'on ne peut pas et on ne pourra jamais, pas de technique pour remédier à ça, à moins qu'on fait évoluer le langage, ainsi mon affirmation n'est pas : "on ne peut pas" :roll: c'est grave!!! N'amènes pas des exemples qui n'ont pas de place ici. Et déjà on est pas là pour comparer des concepts on parle de JavaScript.

Citation:

---

Car il est clair, que la réponse à la question
Où va-t-on avec JavaScript ?
est
On doit le faire disparaître au plus vite.

---

8O Comment oses tu dire une chose pareil, c'est ça ta conclusion? Tu es loins de mes intentions et mes objectifs à l'égard de JavaScript, on ne tue pas les étudiants qui ne bossent pas bien, on essayer de les faire améliorer.
Moi j'accepte les faiblesses de javascript mais je l'utilise et je l'utiliserais encore, il a encore a de beau jour devant lui. Je coderais mes applis Html5 avec, et même Modern UI, il est hors de question de faire du C#/XAML, JavaScript répond au besoin et me permet des gains en productivité.

Je suis toujours contre le fait d'utiliser des outils comme GWT ou JSF pour créer des appli web en java qui sont compilé en javascript et pourtant je suis aussi un développeur java. Je les jamais utilisé et je ne le utiliserais jamais sauf si on me force de le faire. Dans un navigateur il faut du code simple et plus léger que de bouffer la mémoire pour rien, JavaScript est fait pour ça, personne ne dit le contraire. Mais ne mélangeons pas les choses car ça ne se mélange pas.

J'avais dit que je n'interviendrais pas
mais
Je constate,

Citation:

---

j’espère, que pour une fois on lira ce que je dis et non ce qu'on veut me faire dire.

---

tous mes messages ou presque commencent par

Citation:

---

je n'ai pas dit que

---

Tu prends comme exemple le fait qu'on peut ajouter une clef à une map avec le fait d'ajouter un membre à un objet. Je dis que dans les domaines ou on en a besoin l'ajout de membre est une force et l'absence une faiblesse une map ne remplace pas un membre même si on peut trouver des moyens pour simuler un nouveau membre.
Et dans les cas où on n'en a pas besoin, cette caractéristique devient une faiblesse, car elle implique une perte de contrôle de la sécurité de l'objet.

Je me fais quasiment incendier, car je dis que lorsque cela correspond au besoin cette caractéristique est une force. Et je dis que c'est vrai pour toutes les caractéristiques de tous les langages. Lorsqu'elles sont en adéquation avec le besoin, c'est une force. Lorsqu'elles sont en opposition avec le besoin il faut trouver un moyen de contourner ces faiblesses.
Les classes statiques sont une force pour représenter des objets dont la morphologie n'évolue pas. Et une contrainte pour des objets dont la morphologie évolue, car dans ce cas il faut trouver un palliatif.
Les Objets dynamiques sont une force pour représenter des objets dont la morphologie évolue, et une faiblesse pour représenter des objets dont la morphologie n'évolue pas. Cars dans ce cas il faut trouver un palliatif pour garantir qu'ils n'évolueront pas.

À chaque fois que j'ai argumenté sur ce point en tentant de donner des exemples je me suis pris une ruée de brancard me faisant dire que les classes c'est de la merde et mes messages comportent quasiment tous

Citation:

---

je n'ai pas dit que

---

je conclus de toutes ces attaques que dire qu'il y a des cas ou c'est un gros avantage est interdit. Que si j'affirme qu'il y a des besoins pour lesquels c'est une réponse efficace c'est obligatoirement affirmer que tout le reste c'est de la merde*! Car à chaque fois que j'ai dit que cette caractéristique du langage est une force lorsque cela correspond au besoin on me prête le propos suivant, les classes statiques ce n'est pas bien.

Un bébé n'a pas la méthode marcher, mais lorsqu'il devient enfant il la possède, il n'a pas la méthode parler et en devenant enfant il la possède. JS permet de modéliser cela en ajoutant les méthodes au fil du temps Java non. Java ne le pouvant pas il faudra au développeur trouver un moyen de le simuler. Cela ne signifie pas que c'est impossible, cela signifie que le langage ne le propose pas. C’est tout.

Citation:

---

Ah bon tu as dit ça avant?? Tu l'as dit nulle part dans ton message, tu lancé le troll et tu as laissé les gens croire que les langages à typage statique ont des faiblesses, tu as bien bien dit qu'il faut créer" donc obligation et contrainte=> faiblesse. Ce qui représente une affirmation purement fausse et trollesque.

---

Trouve-moi en Java un moyen d'avoir un objet qui sans être réinstancié (crée un nouvel objet) ne possède pas une méthode A à un instant T et la possède à l'instant T + 1. dans un langage à base de classes statiques c'est tout bonnement impossible. Soit ton objet possède la méthode est tu bricoles un moyen quelconque pour que la méthode ne puise pas être invoqué avant l'instant T, mais puisse l'être après. Soit ta classe, ne possède pas la méthode et il faut instancier un nouvel objet. Tu le dis toi même il y a des moyens de faire avec du code ce que le langage JS propose naturellement. Ce qui est exactement ce que je dis.

le propos de départ était Où va-ton avec JS
la réponse de certains était Abandon du prototype au profit de classe statique
Je dis uniquement que faire ça c'est tuer JS, car c'est la caractéristique principale du langage.
Faire ça c'est remplacer JS par un langage type Java.

Si, penser que pour certains besoins avoir un langage qui permet de faire évoluer ses objets dynamiquement est une horreur insupportable. Parce qu'on peut faire quelque chose de semblable avec plus de code dans un langage statique.

Je conclus que c'est aussi vrai pour toutes les autres caractéristiques des autres langages.
donc le shell qui est interprété est une erreur vu qu'on peut faire la même chose en C/C++
etc.

Je ne fais là qu'appliquer ce qu'on me reproche de faire avec les langages à base de classe statiques et que je me refuse à faire, sur d'autre caractéristique d'autres langages.



Lorsque cela correspond au besoin, cette caractéristique est une force.

Lorsque le typage statique ne correspond pas au besoin, c'est une faiblesse.

Et vice versa.
Je n'ai rien dit de plus.

Salut Sekaijin !

j'ai lu bon nombre de tes réponses sur le sujet "ou va t-on avec javascript" ( dont j'étais l'auteur ^^ )

et je suis bien souvent d'accord avec toi, de nombreuse personnes ont posté non pas pour indiquer ou va t-on, mais ou ils aimeraient aller et il aurait fallut recentrer le débat sur l'utilisation actuel du javascript plutôt que sur les orientations et évolutions du langage lui même !

NodeJS aillant explosé ces derniers temps, l'emac 6 arrivant j'espère dans quelques temps également nous allons avoir un langage de programmation qui paliera avec certains de ses défauts ( module, classe, variable ( constantes ... )

Mais n'oublions pas la base de ce langage ! réaliser des interactions intelligentes entre l'interface et l'utilisateur !

Beaucoup d'utilisateurs ( et encore plus depuis mon premier post :'( ) passent par des librairies/ framework sans même comprendre les fondamentaux de ce langage, d'ou les dérives dans ce post/débat ....

Voila mon humble avis

:salut: tout le monde!

Avant d'entrer au fond de mon message que j'ai décomposé en deux pour ne pas fatiguer en lecture , je saisis d'abord l'occasion pour présenter mes excuses à toi sekaijin, si j'étais un peu disons ferme envers toi dans mon dernier message, de même si je n'ai pas interprété à 100% tel que dit. Mais d'une part il faut accepter le critique, on analyse des faits et des propos, possible que je fasse une erreur, mais moi je me base en générale sur plusieurs interventions à toi dans ce forum, je connais parfaitement ton discours.

Je rappel de même que ce qui m'anime aussi c'est dès que tu entends parler du typage static pour le web en générale ou javascript en particulier, tu a tendance à pencher sur le fait de dire que ce n'est pas toujours beau avec si on veut l'utiliser dans le contexte du web, avec plein de messages comme quoi on ne peut pas faire ça là-bas et on ne peut pas faire ceci, c'est faible, c'est limité...

Pourtant je ne prétend pas que tu dis qu'il faut jeter ses langages à typage static, ou fortement typé, mais au lieu d'être plutôt optimiste et voir l’intérêt de l'ajoute du typage le typage static et la POO à base de classe optionnellement à javascript à côté du typage dynamique et le prototypage, ton discours est ferme:

"Non au typage static en JavaScript, dans le contexte de javascript on peut TOUT faire avec, pas de faiblesse; Que ce qu'on ne peut pas faire avec javascript dans sont contexte?" Et là tous les messages plus ou moins à caractère trollesque commencent, c'est ça en fait ce qui me pousse à agir ainsi; Alors e m'excuse encore ;)

Pour répondre à ton message précédant et le défi que tu as posé, il me fallait un peu de temps pour tout rédiger et détailler un certains nombre de chose sur le vrai comportement de JavaScript, et coder quelques exemples, pour bien cadrer le débat.
A suivre....

sentiment personnel, tant pis...

t'es lourd la.lune ... arrête de faire du procès d'intention, et si tu veux faire je ne sais quelle démonstration, essaie peut être de le faire dans un autre topic, non ?

enfin je sais pas, mais le titre du topic, c'est "Où va-t-on avec JavaScript", pas comment utiliser le pattern "décorateur" en java, ou je ne sais quelle autre démo...

Même si la question posée concerne le typage static mais ça permet d'exposer les bases et comment ça se passe de javascript et ma conclusion va dans le sens où va ton avec javascript et pourquoi nous sommes encore là. Quel l’intérêt des autres approches. Ainsi, la problématique posée sur l'ajout dynamique de méthode concerne le typage static à base classe en comparaison avec le prototypage.

Citation:

---

sans être réinstancié (crée un nouvel objet) ne possède pas une méthode A à un instant T et la possède à l'instant T + 1. dans un langage à base de classes statiques c'est tout bonnement impossible

---

J'aurais aimé à ce qu'on évite les message genre "c'est c'est impossible", comment impossible? Et si on veut l'équivalemment d'une chose exactement entre le typage static et dynamique, disons le et il ne faut qu'on se fie aux apparences. :)

Je vais présenter un concept mais avant qu'on me dit comme quoi en javascript tout est objet, car je l'ai lu pas mal de fois sur ce forum comme quoi en javascript tout est objet, alors je le dis avec les preuves à l'appuie que ce n'est pas vrai, en javascript tout n'est pas objet, seuls les membres de type Object le sont.

Je ne dis pas ça parce qu'on utilise pas de constructeur explicitement lorsqu'on manipule des littéraux, mais c'est parce qu'ils ne sont point c'est tout, à moins qu'on utilise des littéraux en créant des objet {..},[...]. La valeur primitive est stocké telle quelle est, il ne fait référence à aucune propriété comme un objet. Pas d’instanciation!! Prenons le soin de bien lire la norme et évitons le jugement sur les comportement superficiels ;)

Si en dehors du site officiel de ECMA, vous pouvez entendre dans certains site dire que: "tout est objet en javascript", il faut faire attention à ce qu'on veut dire!! Je prend l'exemple de w3schools.com, il faut bien lire ce qui est écris après: "tout (sauf..) peut être traité comme des objets" et non pas "tout est toujours traité en objet"

Ce qui se passe c'est qu'en cas de besoin, tout passe simplement par une conversion implicite vers un membre de type Object, en appelant le constructeur correspondant(wrapper) lorsqu'on manipule des littéraux représentant des valeurs primitives ou des variables contenant des valeurs primitives et qu'on veut appliquer des comportements comme sur des objets, c'est ça ce que dit la norme. Une opération abstraite ToObject tel que définit la norme est réalisé.

Il est nulle part dis dans la norme ECMAScript comme quoi les valeurs primitives sont des objets ou qu'il héritent d'une chaîne de prototype quelconque, ce n'est pas vrai. La norme[1] dit:

Citation:

---

4.3.2 primitive value
member of one of the types Undefined, Null, Boolean, Number, or String as defined in Clause 8
NOTE: A primitive value is a datum that is represented directly at the lowest level of the language implementation.

---

Une valeur primitive est une donnée qui est représentée directement au niveau le plus bas de la mise en œuvre de la langue.
Par contre un objet est défini comme une collection de propriétés (là je vais en venir sur la 2e partie), comme c'est dit :

Citation:

---

8.6 The Object Type
An Object is a collection of properties. Each property is either a named data property, a named accessor property, or an internal property...

---

La norme définit toujours en séparant trois choses pour les données, sauf pour Undefined et Null, définit en deux, et Object en un, par exemple pour un number on a : Number Value, Number Type et Nymber Object, le Number Type c'est pour les valeur primitives de type Number. Il ne faut pas mélanger les choses.

Ainsi, si je peux faire 20..toString()//"20" ou 20["toString"]()//"20" c'est juste de la conversion en appelant le constructeur de Number et puis la méthode toString de l'objet Number, ce n'est pas que 20 fût stocké en instanciant un objet :no:. Je peux faire undefined+""// "undefined", mais essayez de faire undefined..toString() ça ne va pas marcher car il n'existe pas de constructeur de type Object pour undefined, et le premier cas il a concaténé en faisant new String(undefined).toString()Pour voir que c'est réellement de la conversion implicite
Si on fait d'abord

Code:

---

1 2 3 4 5

3 instanceof Number;//false 3 instanceof Object;//false var a=3; a instanceof Number;//false a instanceof Object;//false

---

, donc pas d'appel du constructeur, Mais si je fais:

Code:

---

1 2 3 4 5

var b=new 3..constructor();// b=Number{} b instanceof Number;//true b instanceof Object;//true 3..__proto__.meth =function(){ console.log("sss")}; a=new Number();//a==Number{meth:function}

---

On voir que maintenant il fait appel au constructeur Number, et pour les deux derniers lignes vous voyez que c'est le prototype de l'objet Number qui est modifié en ajoutant quelque chose au type.

A présent je vais pourvoir parler sur la problématique posé. Premièrement, il ne faut pas ignorer que ECMAScript définit une méthode tout simplement comme une valeur d'une propriété de l'objet, comme c'est défini déjà: un objet est une collection de propriétés, on map des nom avec des valeurs.

En plus de ça, sans instanciation d'un objet de type Function c'est impossible en javascript de définir une function(méthode) qui est par définition dans le monde de la programmation un ensemble de traitements séquentielles sans état,(des instructions groupés en sous programme comme les procédures), en javascript cette instance est un vrai objet avec plein de propriétés et méthodes propres(en fait des objets de type Function propres).

Dans les langages à typage static l'objet n'est pas crée en portant avec elle le corps de la méthode mais il fait juste référence à la méthode, il ne sera appelé que si la méthode est invoqué et enfin de méthode tout est détruit.

Par suit, l'appel d'une méthode en js ne revient pas à l'appel d'une méthode de l'objet en soit mais pas à l'appel implicite d'une autre méthode de l'objet fourni en valeur de cette propriété de l'objet. La norme parle même "d'implémentation" de la méthode interne(propriété interne) Call pour les fonction quand on les définit.

Relisions ensemble la norme, d'abord c'est quoi une fonction[1]

Citation:

---

4.3.24 function
member of the Object type that is an instance of the standard built-in Function constructor and that may be invoked as a subroutine
NOTE In addition to its named properties, a function contains executable code and state that determine how it behaves when invoked. A function’s code may or may not be written in ECMAScript.

---

Une fonction est un membre du type Object, (ce n'est même pas une valeur primitive, ni un ensemble de traitement séquentiel sans état comme en java), c'est une instance du constructeur Function intégré, il peut être invoqué comme des sous programmes(pas des sous programmes proprement mais comme..)....une fonction contient du code exécutable et un état ​qui détermine son comportement une fois invoqué.

Code:

---

1 2 3

A.m=function(){console.log("methode");}//function (){console.log("methode");} A.m instanceof Object;//true A.m instanceof Function;//true

---

Ainsi, les instructions suivantes sont syntaxiquement différentes mais fonctionnellement les même, même résultat, même comportement:

Code:

---

1 2	obt.A=function(b){console.log('valeur=',this.a+b)}; obt.A=new Function("b","console.log('valeur=',this.a+b)");

---

Et c'est quoi une méthode[1]:

Citation:

---

4.3.27 method
function that is the value of a property
NOTE When a function is called as a method of an object, the object is passed to the function as its this value.

---

Une fonction(donc objet) qui est une valeur d'une propriété...

Le seul intérêt syntaxiquement c'est que le fait de l'invoquer via un objet il passe l'objet comme la valeur this de la fonction, mais cela ne veut pas dire qu'il est lié, on peut corrompre ça en faisant un appel explicite ce qui rend cette technique juste une syntaxique simplifié.

Quand je fais :obj.m(3), il fait tout simplement obj.m.call(obj,3);, et je peux le faire aussi et vu que la méthode est un objet à part, je peux facilement appeler la méthode indépendamment du contenu "this" de l'objet, ce qui fait la porté de "this" n'est en rien devant l'objet Function passé en valeur, qui n'est pas une méthode vraiment de l'objet. exemple de code:

Code:

---

1 2 3 4 5 6 7

var obj={};//Object {} obj.m=function (b){ console.log(this.a+b)} obj.a=3; obj.m(3);//6 obj.m.call(obj,3);//6 obj.m.call({a:20},3);//23 console.log(obj.a===3);//true

---

Il peut facilement ignoré le contenu de l'objet. Par ce que ça ne lui appartient pas, mais on passe l'objet à l'objet Fonction lors de l'invocation.
Une méthode d'un objet en javascript est juste un ensemble de comportement, on les embarque dans un objet et on passe ce dernier à une propriété de l'objet. En plaçant des parenthèses devant la propriété en fournissant des paramètres, il fait son invocation.

Je peux créer une autre manière d'invocation de méthode d'objet et faire aussi passer this à la fonction qui fait l'appel, c'est très simple, même si je ne connais pas les paramètres de la méthode qui sera invoqué.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

Object.prototype.appel=function(nom){ var f=this[nom]; if(!(f instanceof Function)) throw "Erreur de type: ce n'est pas une méthode"; //Je dois enlever le premier argument qui est le nom, pour passer les vrai paramètres //l'objet "agruments" ne possède pas la méthode slice car il n'est pas de type Array for(var i=0;i<arguments.length-1;i++)arguments[i]=arguments[i+1];   return f.apply(this,arguments); }; //============== //POUR TESTER //==============   var a=new Object(); a.val=5; a.ajoute=function (a){ return this.val=this.val+a; }; a.affiche=function(){console.log(this.val);}; console.log(a.ajoute(10));//10 console.log(a.appel("ajoute",10));//20 a.affiche();//20 a["affiche"]();//20 a.appel("affiche");//20 a.somme=function f(a,b,c){ return a+b+c; }; console.log(a.appel("somme",3,3,3));//9

---

Ce n'est pas que dans certains langages à typage static je ne peux pas surcharger l'opérateur des parenthèses que cela veut dire qu'on ne peut pas faire exactement ce qui se passe en javascript, en C++ je peux surcharger les parenthèses et les crochets contrairement à java, en C# je peux aussi surcharger les parenthèses, en C++ je peux définir ce que je veux et faire map["methode"](params) pour invoquer une méthode.

En javascript on a juste une manière simplifié de l'appel, il appel un objet implicitement, comme on a pas de classe. Mais j'ai une manière plus propre et plus jolie a faire avec la POO à base de classe, si l'objectif ce n'est pas de détruire l'instance créer, on ajoute des méthodes et des attributs à la classe, sans détruire l'objet.

Les décorateurs n'héritent pas d'objet étendu comme avec l'héritage classique, mais il le porte par composition, du coup il n'est jamais détruit, il faut aussi différencier entre la référence vers l'objet et un objet. Avec le pattern Décorateur j'ai la même référence qui pointe sur un objet qui décore un autre et chaque fois je lui affecte un nouveau objet décorant l'autre sans que l'autre soit détruit(voir plus de détaille la force du pattern Décorateur Annexe A )

Mais voyons de même que le fait qu'on ajoute des événements à nos composants graphiques qui est le but ultime de javascript(crées pour manipuler des interfaces graphique) est au yeux de ECMAScript de simples méthodes aux objets.

ECMAScript ne définit pas d’événement dans la norme, les événements est une manipulation du langage par l'API W3C, quand je clique sur un bouton bt1, c'est juste un appel du corps de la méthode stocké dans la propriété, en faisant bt1.onclick() implicitement bt1.onclick.call(), rien ne m'empêche de déclencher le comportement que fera un bouton manuellement dans une méthode, en faisant la même chose bt1.onclick(), j'appel la méthode ajouté à l'objet, c'est ça le but de javascript.

Pour s'approcher du but, prenons l'exemple de Nashorn , actuellement au lieu d'être borné en java pour les applis natives je peux coder mes applications JavaFX en javascript, alors en JavaFX par exemple pour ajouter une méthode à un bouton je fais la même chose, j'ajoute un objet Fonction à l'objet

Code:

---

1 2 3 4

var button = new Button(); button.text = "Dire 'Bonjour !'"; button.onAction = function() {print("Bonjour tout le monde!");//print sur le jdk est égale à console.log }

---

Là je fais un set, affectation d'un objet à une propriété interne. field.setValue("test2") revient à faire field.value="test2"Et en Java et les autre lagunages à typage static? Comment je peux ajouter cette même méthode sur un bouton après avoir instancié un objet de type Button, je fais tout simplement:

Code:

---

1 2 3 4 5 6

Button btn=new Button(); btn.setText("Dire 'Bonjour !'"); btn.setOnAction(new EventHandler<ActionEvent>() { public void handle(ActionEvent event) { System.out.println("Bonjour tout le monde");} });

---

Je passe par une classe anonyme comme en javascript j'utilise un fonction anonyme, qui est un Objet que j'instancie, je peux aussi donné une classe non anonyme comme en javascript je peux donner une fonction non anonyme, afin de pouvoir a partager entre plusieurs objets.

Ce qu'il faut éviter aussi c'est de dire que les langages à typage static ne sont pas fait pour ça, donc toutes les interfaces graphiques codés en Swing,AWT,SWT,JavaFX ne sont pas faire pour ça, tous ces années ils ont vécus et qu'ils continuent aussi, ils étaient entrain de bidouiller? Mais c'est eux même qui ont crée javascript alors comment ils se sont trompés et continuent à utiliser.

Alors que cette syntaxe, non seulement non IDE génèrent automatiquement, mais on a voulu faire quelque chose qui sera bien compilé et bien structuré, et plus de gains en performance. Que la syntaxe en java enchante les codeurs ou pas, on fait la même chose qu'en javascript. EventHandler est aussi une interface donc classe purement abstraite, dont on doit définit la méthode handle.

Mais avec les expression lamda existant en java et C++,C# on a facilité juste la syntaxe car le compilateur est plus intelligent, il connaît les interfaces à chercher, et il n'instancie pas un objet comme les class anonymes ou les fonction annymes, mais il fait appel à l'expression au moment de l’exécution, pas besoin d'instancier un objet et la placer en mémoire.

Code:

---

1 2 3

btn.setOnAction((ActionEvent event)-> { System.out.println("Bonjour tout le monde");} );

---

Alors de la même manière que je crée un objet en javascript et je crée un objet en java, pour définir un comportement dynamiquement.

Citation:

---

Envoyé par sekaijin

Tu prends comme exemple le fait qu'on peut ajouter une clef à une map avec le fait d'ajouter un membre à un objet. Je dis que dans les domaines ou on en a besoin l'ajout de membre est une force et l'absence une faiblesse une map ne remplace pas un membre même si on peut trouver des moyens pour simuler un nouveau membre.

---

Il ne faut pas ignorer que la norme ECMAScript aussi définit l'accès aux propriétés et la récupération comme comme la manipulation d'un map. Par définition, les ajouts et récupération sont définis par les opération GetValue (V) et PutValue (V, W)(voir section 8.7.1 et 8.7.1)exactement comme une map, chaque objet possède en interne la propriété put et get, le reste sont des sucres syntaxiques.

Un Objet en javascript est une collection de propriétés ce n'est pas le cas dans les autres langages à base de classe. Essayons de comprendre, il n y a pas de la magie dans la programmation ajouter dynamiquement c'est une structure de données dynamique point barre qu'on peut faire même avec le langage C

Je me pose la question membre en javascript est-il synonyme de a.membre mais quand je fais a["membre1"], membre1 n'est pas membre, n'est ce pas? et quand je fais a["membre"]["membre2"], membre2 n'appartient pas à l'objet a, mais seulement à membre, n'est ce pas? il y a seulement des objets simples, les objets complexes ça n'existe pas? et pourtant un objet en javascript est un objet complexe et simple dans l’apparence.

Ce qui se passe, c'est comme en C#6 où ils ont étendu les objets indexés(map et autres) avant on pourrait faire seulement obj["cle"]="valeur" mais maintenant on va pouvoir faire obj.cle, et dans tous les deux cas c'est obj.put("cle","valeu") et obj.get("cle"). Rien ne dit que le langage souffrait d'une faiblesse avant cette sucre syntaxique?

S'il y a simulation c'est bien la notation de pointé en javascript car il cache de que définit la norme et ce qui se passe vraiment, alors que ce n'est même pas le fond du langage qui code le moteur mais la simple structure interne d'un objet javascript. Les attributs et propriétés crée à l’interne de l'objet.

Avec Nashorn je gère un objet map en javascript comme un simple objet javascript si j'instancie une map, mais avec Nashorn j'ai des outils de plus, la méthode put() et get() rendu à la portée des utilisateurs,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

var objet = new java.util.HashMap(); // accès avec les méthodes get et put objet.put('js', 'nashorn'); print(objet.get('js'));//=>nashorn // accès par clé et la syntaxe propre des proprietés print(objet['js']);//=>nashorn print(objet.js);//=>nashorn objet['language'] = 'java'; print(objet.get("language"));//=>java print(objet.language);//=>java print(objet['language']);//=>java objet.answer = 42 print(objet.get("answer"))//=>42 objet.put("affiche", function(){ print("Bonjour"); }); objet.affiche();//=>Bonjour objet.affiche2= function(nom){ print("Salut "+nom +" !"); }; objet.get("affiche2")("sekaijin"); //=>Salut sekaijin ! objet.get("affiche2").call(objet,"sekaijin"); //=>Salut sekaijin !

---

Ainsi, en plus que c'est du simple mappage, mais aucune syntaxe n'est synonyme de faiblesse ou de force devant l'autre.

Pour cela, afin de réaliser un comportement purement dynamique en java en attribut et méthode, en quelque minute j'ai défini moi même une classe représentant un objet dynamic selon mon besoin, que je peux utiliser toujours et elle est générique et ma map est privé, seul moi a accès, et pas de possibilité à l'utilisateur d'appeler la méthode remove pour tuer mon objet

Pour ajouter une méthode j'ai crée une interface Méthode pour n'importe quel méthode, elle a besoin connaitre la type "Type" de retour de la méthode. Ce sont des choses existantes dans l'API standard de java mais je préfère créer moi même ce que je veux.

Code:

---

1 2 3

public interface Methode<Type> { public Type call(DynObject This, Object... args); }

---

Voici ma classe, l'utilisateur à droit à _g() pour faire un get de propriété et un _s() pour un set d'un valeur et une une méthode appel(), et un message d'erreur si ce n'est pas une fonction

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

public class DynObject { private final HashMap map=new HashMap(); //je définit la méthode get _génriquement public <U> U _g(String s){ return (U)map.get(s); } //je définit la méthode _s public void _s(String s, Object o){ this.map.put(s, o); } public <Type> Type appel(String name_methode, Object...args){ //Pour ne pas rompre le programme en cas d'erreur mais ça peut compiler sans le try catch try{ Methode<Type> methode=this._g(name_methode); //La technique d'inference de type permet de savoir le type de retour qu'il est correct return methode.call(this, args);   }catch(ClassCastException e){ System.err.println(name_methode+" n'est pas une méthode"); return null; } } }//DynObject

---

Donc, après je fais ce que je veux dans une méthode principale où n'importe et quand je crée une fonction mon IDE me génère le squelette par défaut de des l'interface Function je lui donne les types c'est tout et puis je code seulement,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

DynObject obj=new DynObject(); obj._s("cool",true); obj._s("id",2014); obj._s("log","La.lune"); obj._s("adress",new String[4]); obj._s("sous_membre",new DynObject()); obj._s("affiche", (Methode<Boolean>) (DynObject This, Object... args1) -> { System.out.println("ID :"+This._g("id")+", " + "Tu es cool :"+This._g("cool")+", " + "Login :"+This._g("log")); return true; }); obj._s("somme", (Methode<Integer>) (DynObject This, Object... argv) -> { return (int) argv[0] + (int) argv[1]; }); String longin=obj._g("log"); boolean cool=obj._g("cool"); int id= obj._g("id"); obj.appel("affiche");//<=>obj.obj["affiche"]() //ou bien obj.<Methode>_g("affiche").call(obj); int somme=obj.appel("somme",3,7);//<=>obj.obj["somme"](3,7)<=>obj.obj["somme"](3,7)   System.out.println("valeur="+somme); System.out.println("Deuxième affichage"); System.out.println("ID :"+id+", " +" Tu es cool :"+cool+", " +" Login :"+longin);

---

Affichage:

Citation:

---

ID :2014, Tu es cool :true, Login :La.lune
ID :2014, Tu es cool :true, Login :La.lune
valeur=10
Deuxième affichage
ID :2014, Tu es cool :true, Login :La.lune

---

Que ce qui se passe en JavaScript ne se passe pas en Java, fonctionnellement j'ai la même chose seulement les syntaxes différent. Ici j'ai mis le try catch dans appel pour ne pas que le programme s’arrête mais en cas de fourniture d'un objet autre qu'une méthode, mais ça peut compiler facilement.

Citation:

---

Envoyé par sekaijin

Un bébé n'a pas la méthode marcher, mais lorsqu'il devient enfant il la possède, il n'a pas la méthode parler et en devenant enfant il la possède. JS permet de modéliser cela en ajoutant les méthodes au fil du temps Java non

---

Ah bon! les interfaces graphiques en java viennent tous avec les actions a réaliser déjà faites?
Là je donne un :plusser: à ceci

Citation:

---

Envoyé par le_chomeur

Mais n'oublions pas la base de ce langage ! réaliser des interactions intelligentes entre l'interface et l'utilisateur !

---

Ce que j'aurais aimé souligner c'est qu'il ne faut pas détourner javascript de son but ultime, et avec cet exemple du bébé, je ne vois pas sa place ici. Un bébé oui, il n'est pas né avec la fonction marcher ou parler. Mais il ne faut pas oublier que c'est impossible à un bébé d'avoir dans le future la fonction imprimer ou démarrer, ou voler comme un oiseaux. Toutes les fonctions sont préalablement connus, mais on les actives après.

Et pour faire marcher le bébé je ne suis pas obliger de faire une opération sur l'enfant pour lui faire marcher. Au cours du temps, j'appel des des méthodes, des getter et des setters pour remplir ses propriétés(connaissance, énergie, fortifier ses muscles) et au court du temps on active les méthodes qui sont susceptibles.

Ainsi, soit je lui ajoute des valeurs à ses attributs dynamiquement et définir les nouveau comportement à leurs places soit je lui décore avec une nouvelle méthode et fonctionnalité sans le tuer.

JavaScript n'est pas fait pour venir faire div.onfocus=function(){} car il n'existe pas quelque chose qui s'appel focus sur un div.

Par suite, il ne faut pas utiliser les concepts de javascript là où ils ne sont pas crées pour. Si je n'ai pas besoin pour un composant graphique déjà crée, le but d'une méthode c'est factoriser un ensemble de tache pour plusieurs objet de même types, et là je passe par la définition via la propriété prototype pour que tous les objets bénéficient, donc comme les classes, même si en javascript je crée un objet.

Faire sortir la notion de méthode des deux concepts revient à utiliser javascript en dehors de son but, et pondre des méthodes pour chaque objet que seul le codeur connait.

J'aurais aimé souligner qu'un développeur voit la finalité d'une chose et non pas la syntaxe, les syntaxes oui c'est jolie et c'est beau et souple, mais ce n'est pas une finalité en soi. Le faite d'écrire en CoffeeScript somme=(a,b)->a+b; et qu'en javascript je dois écrire function somme(a,b){ return a+b;} ça ne veut pas dire que CoffeeScript est plus fort que Javascript et que ce dernier est faible et il n'est pas fait pour ça. De même que document.getElementByID("id") ne veut pas dire que JQuery est plus fort que l'API standard, il offre juste une souplesse au détriment de la consommation de la mémoire et des performances

Conclusion

Le monde n'est pas dans l'erreur s'ils reconnaissent en principe l’intérêt de CoffeScript, TypeScript, Dart, des outils comme GWT,JSF en java et fond de bon programme dans le contexte de JavaScript et ça marche très bien. Même si c'est bien mais ce n'est vraiment la bonne solution. Je serais obligé à migrer vers Dart pour un gros projet, par ce que je n'ai pas le choix.

Nous ce qu'on veut en JavaScript c'est qu'on ait le choix de faire autre chose que le prototypage sans tuer cette belle notion qui nous sert aussi. La grosse erreur faite pour javascript c'est l'enterrement de la version 4 de ECMAScript et on est passé après à la version 5.

Le ES4[2] permettrait d'avoir toutes les notions objets à base de classe(interface, package, class,encapsulation, module), et tout ça sa tuer le prototypage. Il est même dit que toute classe posséderait la propriété prototype, ce qui n'existe pas dans les langages à typage static. Qui dit qu'on doit tuer le prototypage?

Par suite avec les contestations par ici par là comme quoi javascript dévie son chemin, ils ont enterré la norme et voila comment le monde est devenu, pour se rendre compte 3 ou 4 ans ans après qu'ils ont commis une grosse bêtise.

Ceux là qui n'ont même pas participé à son élaboration, ce sont ceux qui font l'hypocrisie aujourd'hui et viennent pondre TypeScript et Dart. Google n'a fait que copier ES4, il savait ce que le web allait devenir, et au lieu de se rattraper, il a pondu un autre langages alors que le but du web c'est la standardisation des choses et le multi-plateforme le maximum possible, rien qu'avec js on souffre parfois pour le cross browser imaginez si on fait du web comme en natif :aie:

Quand Abobe, Mozilla, Opera et les autres ont crée la spécification où est ce qu'ils étaient? Du côté des contre bien sûr, possible parce qu'ils cachaient déjà leur projet. Comment Google pourra convaincre ces concurrents d'adopter son langage alors que lui même a laissé tomber ES4 proposé par ses concurrents :cfou:.
Ou bien ils veulent à tout prit que la valeur de javascript dans le web soit effacé dans l'histoire et que ça revient à leur propre langages :calim2:. Ainsi, on sera dans certains cas obligé de migrer si les navigateur n’implémente pas ces principe de la POO en javascript.

Liens de reference
[1]ECMA Internationale Standard ECMA-262,Edition 5.1,Juin 2011
[2]Référence de la proposition de ECMAScript 4

Annexe A
Exemple d'utilisation du pattern Décorateur;

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

abstract class AbstractPersonne{ String nom; int age; //Par défaut on a ça abstract void pleurer(); abstract void dormir(); } //Un bébé est né une seule fois class BB extends AbstractPersonne{     public BB(String nom, int age) { this.nom=nom; this.age=age; }   void pleurer(){ System.out.println(nom+" pleure");} void dormir(){ System.out.println(nom+" dort");} } abstract class Decorateur extends AbstractPersonne{ AbstractPersonne decoré; public Decorateur(AbstractPersonne decoré) { this.decoré = decoré; } public void pleurer(){ decoré.pleurer();}   public void dormir(){ decoré.dormir();}   public AbstractPersonne getDecoré() { return decoré; } } class FuncsEnfant extends Decorateur{   public FuncsEnfant(AbstractPersonne personne) { super(personne); } public void parler(){ System.out.println(this.getDecoré().nom+" parle"); } public void marcher(){ System.out.println(this.getDecoré().nom+" marche"); } } class FuncsAdo extends Decorateur {   public FuncsAdo(AbstractPersonne personne) { super(personne); } public void raisonner(){ System.out.println(this.getDecoré().nom+" raisonne"); } //je connais l'ierarchie @Override public AbstractPersonne getDecoré() { Decorateur décoration=(Decorateur)decoré; return décoration.getDecoré(); } }   public class Application{   public static void main(String... args) { AbstractPersonne personne; personne=new BB("Toto", 0); personne.pleurer(); personne.dormir(); //Je décore mon BB sans le détruire personne=new FuncsEnfant(personne); ((FuncsEnfant)personne).marcher(); ((FuncsEnfant)personne).parler(); personne.pleurer(); Object décoré=((FuncsEnfant)personne).getDecoré(); System.out.println("1:"+(décoré instanceof BB)); personne=new FuncsAdo(personne); Object décoré2=((FuncsAdo)personne).getDecoré(); System.out.println("2:"+(décoré2 instanceof BB));

---

La bébé n'est pas tué pour devenir enfant, il est décoré, il reste toujours en mémoire, est qu'on re-instancie l'objet? Voici le résultat du teste

Citation:

---

Toto pleure
Toto dort
Toto marche
Toto parle
Toto pleure
1:true
2:true

---

Citation:

---

Envoyé par fredoche

sentiment personnel, tant pis...

---

La question n'est pas question de sentiment, mais il ne faut pas qu'on véhicule de fausses informations. Il ne faut pas oublier qu'avec le typage dynamique c'est le développeur qui souffre dans certains cas avec le typage dynamique encore faiblement, c'est cette souffrance qu'on veut éviter, on aime tous les facilité et les bonnes syntaxes, et la bonne structure du code.

Il ne faut pas qu'en développant mon jeu je connais tous les caractéristiques de mes objets, alors je dois passer par quelque chose de dynamique après je vais me mordre les doigt après en cas de bug.

Nous on veut le choix en javascript c'est ça mon objectif.

Bonjour,

Je viens de lire attentivement tes interventions.

Je suis entièrement d'accord avec toi "nous devons avoir le choix"
HTML permet d'embarquer des scripts et il est possible d'utiliser d'autres langages que JavaScript
En 1996 j'embarquais du TCL et IE permettait d'utiliser VBS.

Mais, je ne suis pas d'accord lorsque certains dissent qu’il faut supprimer les prototypes et le typage dynamique de JS et le remplacer par des classes et du typage Satique.

EcmaScript n'est pas utilisé que dans le WEB et je ne suis pas toujours très content de la façon don EcmaScript est intégré au navigateur la Partie W3C de JS est pour moi plus problématique que le langage.

Lorsqu’on utilise EcmaScript dans d'autres contextes que le Web, sa capacité à faire évoluer ces objets est pertinente efficace.

Je sais que cela à un coût et je suis le premier à dire qu'il faut utiliser la modélisation statique lorsque cela est pertinent.

Je pense qu'effectivement tout comme par le passé avec le shellScript on est arrivé à des usages dans le navigateur qui ne sont plus dans le scope de départ. Il ne s'agit plus d'écrire un petit script pour gérer un évènement. Aujourd'hui on écrit de véritable application quasi 100% JS et là le modèle de programmation proposé n'est peut être la le meilleur.

Pour faire des IHM, la modélisation par classes a fait ses preuves.

Je suis personnellement confronté à la situation inverse tous les jours.
J'ai des dev fait en JAVA dans lequel je manipule des "objets" très mouvants aux contours flous.

Pour y parvenir, j'ai fini par utiliser des HashMap. Du coup tous mes "objets" sont des HashMap. À quoi peut me servir le typage statique ? Je ne peux pas utiliser le polymorphisme Java puisque ce sont tous des HashMap
Je dois donc faire ce qui est le pire en java des if et switch pour déterminer quelle méthode statique d'un objet statique utiliser sur ma HashMap, idéalement il me faudrait pouvoir associer à ma HashMap un objet qui possède toutes les méthodes le concernant. Mais ayant quelques centaines de méthodes il me faudrait alors prévoir toutes les combinaisons possibles. N'ayant pas connaissance avant l'exécution du contenu de ces "objets" je ne peux pas faire des classes pour chaque "type d'objet" que je reçois.
Au final sur cette partie je fais du dev procédural en Java.

Avec Nashorn (Js dans Java8), j'ai le meilleur des deux mondes. Pour cette partie particulièrement peu typée, JS est une force. Pour tout le reste les classes java font des merveilles.
Malheureusement Java8 n'est pas encore une cible pour la mise en production. Mais tous mes tests montrent qu’utiliser JS pour cette partie donne un code simple, robuste, adaptable, maintenable, évolutif, et concis.
Tout le contraire des mots que je lis dans les critiques de JavaScript. Et le code JS étant dans le Jar Java il n'est pas modifiable par l'utilisateur donc je n'ai pas de Pb de sécurité plus important qu'avec le reste de l'appli.

J'aimerais dans le monde web voir apparaitre plusieurs choses.
D'autres langages supportés en standard dans le navigateur pour cibler les nouveaux usages.
J'aimerais aussi pouvoir envoyer au navigateur un "lanceur d'app". Un mime type qui dirait au navigateur charge ce JS (ou un autre langage) et exécute-le. Je trouve très con de faire une page HTML comme

Code:

---

<html<head><script src="myapp.js"></script></head></html>

---

j'aimerais bien pouvoir dire au navigateur charge myapp.js et exécute-la. Je n'ai jamais de code HTML dans mes applis.

A+JYT

Bonsoir

J'ai trouvé une opinion intéressante, malheureusement en anglais, sur l'inflation des "frameworks" et le devenir du JS

En bref (ce n'est pas une traduction du texte, juste un reflet, les opinions auxquelles j'adhère de plus en plus) :

Oublions les mésaventures provoquées par les navigateurs obsolètes et mettons à la poubelle les rustines développées pour pallier leurs insuffisances.

En 2014, avec l'évolution des codes (HTML5, CSS3, JS ES6) et l'évolution des navigateurs dignes de ce nom, il est devenu plus intéressant d'utiliser le JS que de s'enfermer dans le carcan d'un "framework" aussi bon soit-il.

Il faut bien distinguer une "library" (code effectuant une tâche précise), qui sera toujours utile, d'un "framework" qui vous impose une manière de penser donc de coder.

Idem pour l'UI, les nouveaux standards permettent la création d'éléments réutilisables (Web Components). Pour l'instant plusieurs techniques nécessitent encore l'usage de "polyfils".

Quelques liens utiles :

• Object.observe
• Promises
• HTML Imports
• HTML Templates
• Custom Elements
• Shadow DOM

• Polymer
• X-Tag
• Bosonic

• Brick Download
• X-Tag Download

Ce n'est pas qu'une question de richesse et de puissance du langage / de l'outil. Les frameworks servent surtout à fixer un cadre. Si on s'engage à suivre rigoureusement la méthode imposée par un framework, on évite en théorie plusieurs erreurs de parcours classiques. C'est aussi une manière d'homogénéiser la façon de coder au sein d'une équipe. Par exemple, EcmaScript 6 apporte la notation des classes. Entre class, l'opérateur new et Object.create, ça fait trois façons différentes de faire la prog objet. Si on ne se fixe pas une ligne de conduite, ça peut vite devenir un sacré bazar.

Une citation que j'ai lu je ne sais plus où :

Citation:

---

Les frameworks, c'est comme les pistes de skis. C'est moins fun que le hors-pistes, mais t'as plus de chances d'en sortir indemne.

---

Je connaissais pas Bosonic, ça a l'air cool ! Des retours ?

Citation:

---

Il faut bien distinguer une "library" (code effectuant une tâche précise), qui sera toujours utile, d'un "framework" qui vous impose une manière de penser donc de coder.

---

Pourtant côté serveur, les contraintes imposés par l'utilisation d'un framework sont a priori les mêmes et pourtant ceux-ci se sont clairement fait une place et font maintenant partie intégrante du bagage de tout "développeur web". Leurs avantages ne sont plus à prouver, le principal étant de se concentrer sur les points spécifiques de notre projet plutôt que s'acharner à réécrire des fonctions récurrentes à tout développement, et dans bien des cas (il reste des cas spécifiques ou leur utilisation ne s'impose pas bien entendu), ceux-ci sont clairement profitables aux développeurs malgré les inconvénients qu'ils engendrent -car il y en a aussi bien sûr-.

Alors bien que les langages utilisés soient différent, pourquoi en serait-il différemment côté client ?

Le nombre de library existent sur le web est énorme, d’ailleurs elle représente la plus grande partie de l'utilisation de Github :o (13.98% sur 144 langages)
Et c'est vrai aussi que de plus en plus de personnes ce dise développeur JS alors qu'ils importent des bibliothèques et tape une ligne de code.

Serte les bibliothèques sont bien dans le sens de la rapidité d'installation et d'utilisation mais très peut de gens vont voir ce qu'il se passe derrière.

L'écrire soit même s'est mieux à mon gout. :D

Citation:

---

Envoyé par phildes2

Je pose la question au sujet de TypeScript car il est commandité par un acteur majeur de l'informatique et risque de s'imposer dans les normes futures du Javascript (je suppose donc que cette question correspond au sujet)

Le Javascript est très complet et me satisfait parfaitement. Le javascript est un langage qui possède des propriétés très intéressantes.
Notamment l'absence de typage, qui n'est peut-être pas un oubli, mais la volonté de proposer un autre format de programmation que celui qui était répandu dans les années 80.

---

Bonjour, quelques arguments en faveur de TypeScript :

* Le langage TS est un sur-ensemble de EcmaScript 5. Cela signifie que n'importe quel code ES5 est valide en TS. Les lib jQuery et autres sont alors utilisables (contrairement à Dart). Le temps d'apprentissage est réduit.
* Le compilateur TS produit du code JS propre et indépendant (contrairement à Traceur qui génère un code JS dépendant d'un runtime). Dans le pire des cas, s'il fallait quitter la technologie, le code JS produit par TS serait une base de travail convenable.
* À part le typage qui est une innovation de TS, les autres éléments du langages sont des implémentations du brouillon de ES6 (voir un résumé ici). Il s'agit des classes, des modules (espaces de nommage), des paramètres par défaut et de l'opérateur "flêche". Cela implique que le compilateur TS est destiné à être simplifié et ne prendre en compte que le typage.
* Concernant le typage : il apporte un confort non négligeable dans l'assistance fournie par les IDE. Le mécanisme des interfaces/implémentations dans TS est plus souple que dans les langages typés classiques et s'intègre bien dans la manière de penser JS. C'est à mon sens un apport considérable.
* TS ajoute aussi la notion d'accessibilité dans les classes : les membres peuvent être déclarés privés.
* La technologie est open-source et utilisable en dehors des autres produits Microsoft (comme ce n'est pas dans les habitudes de Microsoft, mieux vaut vérifier).

Utilisez le Playground pour tester. Je suggère d'y coller par exemple ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

interface HelloWorld { sayHello(); }   class MyFirstClass implements HelloWorld { constructor(private name: string = 'World') { } public sayHello() { return "Hello, " + this.name + '!'; } }   function test(obj: HelloWorld) { obj.sayHello(); }   var obj = new MyFirstClass('John'); test(obj);

---

Supprimez éventuellement la déclaration "implements HelloWorld" : elle est optionnelle.

Le code dynamique est toujours possible. Par exemple ajoutez ceci qui compilera sans problème :

Code:

---

1 2 3

obj['otherMethod'] = function () { alert('Other'); };

---

Bonjour, je ne suis qu'un enfant par rapports aux autres dev JS, néanmoins, pour moi, Js est le futur. Je trouve Java assez austère, en JS, c'est super ludique. Quand au concept de ne pas re-faire la roue, il est poussé au max avec
1. Jquery
2. Tous les plugs-ins existant.


Mon trip: Ce serait de faire dialoguer JS avec d'autres langages (JAva, C++) pour de la robotique, et en fait tout piloter à partir de JS.

Toute la bureautique peut être faite sur JS et les derniers navigateurs. Je ne vois pas l'intérêt de passer sur des langages plus "perfectionnés" pour faire de la bureautique.

J'ai pas encore fait d'héritage par contre, le mot "extends "manque beaucoup !

Par contre, réaliser une constructeur en JS est super simple ! J'adore ça !

Quand à JSON, c'est un format EXCELLENT et très accessible ! Bref? pour moi JS c'est l'avenir, et les autres langages ont du soucis à se faire...

Je pense que C et C++ n'ont pas trop de soucis à se faire :P

Il y a des centaines de langages de programmation, avec leurs points faibles et points forts. J'adore le JS mais j'ai bien conscience de ses nombreux points faibles. Qualitativement, les nouveaux langages comme Swift ou Dart sont meilleurs. C'est normal, ils ont été conçus pour palier aux défauts des précédents. Mais ce n'est pas forcément la qualité qui détermine l'adoption d'un langage. Un très bon langage peut très vite tomber dans l'oubli si les plates-formes et l'outillage ne suit pas

Dans les systèmes embarqués où la fiabilité du code est indispensable, je ne pense pas qu'un langage comme JavaScript ait la moindre chance de percer.

Citation:

---

Envoyé par MoumouteMasters

J'ai pas encore fait d'héritage par contre, le mot "extends "manque beaucoup !

---

La plupart du temps, l'héritage est une mauvaise pratique, ça ne fait pas de mal de s'en passer. Les interfaces et implémentations sont bien plus élégantes.

Et l'héritage d'interfaces ? :P

Je ne pense pas que proclamer que tel concept est une mauvaise pratique soit vraiment très constructif, tout dépend de comment il est concrétisé et à quelle situation on fait face. On peut trouver des cas qui se prêtent mal à l'héritage, et d'autres qui se prêtent mal aux interfaces. On devrait plutôt se féliciter d'avoir un langage très flexible qui peut jongler facilement entre ces paradigmes, en tout cas plus facilement qu'avec d'autres technos *kof kof* JEE *kof*

Concernant l'héritage, c'est faisable en JS mais c'est clair que la syntaxe est pénible avec cette saleté d'opérateur new. Heureusement, l'avantage quand une syntaxe ne nous plaît pas est qu'on peut construire quelque-chose de plus plaisant autour. Et puis il y a le mot-clé extends qui débarque avec les classes ES2015 d'ici la fin de l'année, même si selon moi c'est faire un autre trou dans le mur plutôt que de réparer la porte.

Citation:

---

Envoyé par SylvainPV

On devrait plutôt se féliciter d'avoir un langage très flexible qui peut jongler facilement entre ces paradigmes, en tout cas plus facilement qu'avec d'autres technos [SIZE=1]*kof kof* JEE *kof*

---

Espérons que des Javaïstes ne passent pas dans le coin :mouarf:
Ils sont encore nombreux les bougres !

Sur l'héritage de classes, c'était un avis à propos de la POO en général et pas spécialement pour JavaScript.

L'héritage est souvent utilisé comme une technique de réutilisation du code. Et c'est mal. L'héritage devrait s'en tenir à sa définition en UML : une spécialisation sur un plan fonctionnel. C'est-à-dire que la raison de l'héritage doit se trouver dans le sens que les objets ont et non pas dans des fonctionnalités en commun. Pour réutiliser, la manière propre est la délégation. Or les programmeurs en POO font massivement usage de l'héritage en tant que mécanisme de réutilisation.

Pourquoi cette forme de réutilisation est mauvaise ? Car l'héritage casse le principe d'encapsulation. Dans la pratique, une modification dans le code de la classe mère ou dans celui de la classe enfant nécessite que le développeur soit conscient de l'implémentation interne des deux classes sous peine d'effets de bord.

Il reste la spécialisation, et celle-ci est un cas rare en programmation. Dans mon expérience, dans un programme constitué d'une centaine de classes, on peut trouver peut-être cinq cas où la spécialisation a du sens. Or les langages incitent au contraire à un héritage tout azimut. Par exemple en Java les classes et les méthodes devraient être "final" (héritage interdit) par défaut, et c'est le contraire : si on ne précise rien, tout est héritable. Par exemple l'accesseur "protected" devrait être utilisé avec parcimonie, et l'équipe de TypeScript s'est dépêchée de l'implémenter à cause de la forte demande de la communauté. Sans parler du mot-clé "extends" qui signifie le contraire de "spécialiser" !

L'héritage des interfaces : il est en pratique utilisé à bon escient. Une interface est un contrat. Il faudrait vraiment être paresseux pour vouloir hériter juste dans le but de réutiliser des définitions. Et puis ça a des conséquences : par exemple vous voulez hériter quatre méthodes d'une interface mère, mais la cinquième méthode de l'interface mère, celle dont vous n'avez pas besoin, il faudra bien ensuite que la classe l'implémente pour rien, et, heureusement, même les développeurs les moins élégants répugnent à cela. Donc dans la pratique, l'écueil de l'héritage pour réutilisation est mieux évité.


Sinon je trouve ObjectModel intéressant. Une manière de faire des vérifications de types en dynamique.

"c'est mal". Cela illustre bien là où je veux en venir, le bien et le mal sont des concepts absolus or rien n'est absolu, tout est relatif. L'héritage casse le principe d'encapsulation certes, mais la délégation casse le principe de substitution, alias polymorphisme. Quel principe serait plus important qu'un autre en toutes circonstances ? De manière absolue, il n'y a pas de paradigme supérieur aux autres. Tout dépend de la situation rencontrée. Même si ça ne concerne que 5% des classes d'un projet, il y aura quand même 5% de cas où l'héritage, "c'est bien".

Après je suis d'accord pour dire qu'on bourre le crâne des étudiants avec de l'héritage à cinq niveaux de profondeur, avec les profs qui se creusent la cervelle pour trouver des exemples pertinents quand ils savent pertinemment qu'un cas similaire ne se retrouvera probablement jamais sur un vrai projet. Mais bon, si chacun prêche pour sa paroisse, on est pas sortis de l'auberge !

Citation:

---

Envoyé par SylvainPV

[…] mais la délégation casse le principe de substitution, alias polymorphisme.

---

Dans un contexte d'héritage de classes, le principe de substitution n'a de sens qu'avec une spécialisation. On a un type général, puis un sous-type (plus spécialisé) qui peut se faire passer pour le type général :

Citation:

---

More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping,

---

Mais dès qu'un langage le propose, la manière habituelle et élégante de faire de la substitution, c'est le mécanisme d'implémentation des interfaces.
Hé oui.
TypeScript wins! :p

Quand on développe avec le modèle MVC, on a bien souvent un contrôleur père (pourquoi pas abstrait même si on veut), avec des contrôleurs fils qui seront chacun une séparation de grandes fonctionnalités du projet (en gros).

J'ai donc une question : est-ce un bon cas d'utilisation de l'héritage ? Si oui, bon ben l'utilisation de l'héritage c'est quand même vachement utile (parce que du coup ça s'applique aussi aux vues et aux modèles) et du coup je pense que c'est plus de 5% des cas, si non, j'aimerai bien qu'on m'explique pourquoi parce que je vois pas ce qui n'est pas bien

Euh, "MVC" dans quel sens ? AngularJS ?
Angular génère un héritage de scopes/contrôleurs, c'est d'ailleurs un point qui pose problème parce qu'il n'est pas intuitif. Mais pour séparer différentes parties de l'interface, les directives paraissent indiquées, non ?

Les frameworks incitent à l'héritage, pas toujours à bon escient. Certes il vaut mieux programmer de la manière prévue par les concepteurs du framework, mais ça ne prouve rien.

Citation:

---

Envoyé par Tarh_

la manière habituelle et élégante

---

habituel et élégant sont deux critères totalement subjectifs :)