Discussion :

[sekaijin]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[phildes2]

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.

[ascito]

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

[sekaijin]

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

A+JYT

[phildes2]

je ne pense pas

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

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.

[sekaijin]

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

[phildes2]

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 ?

[sekaijin]

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

[phildes2]

Toutes ces explications sont tr�s instructive (car tr�s didactique ). 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

[la.lune]

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

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

[sekaijin]

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

[la.lune]

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 .

[la.lune]

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 c'est grave!!!

[sekaijin]

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

[la.lune]

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.

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.

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� , c'est �a le sujet, il faut bien lire ce que j'ai �cris, voci mon message int�gral

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.

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.

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.

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.

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.

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.

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.

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

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:

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

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.

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.

[sekaijin]

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

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

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

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.

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.

[le_chomeur]

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

[la.lune]

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

[fredoche]

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

[la.lune]

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.

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:

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 :

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

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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]:

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 javascript :

S�lectionner tout - Visualiser dans une fen�tre � part

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 javascript :

S�lectionner tout - Visualiser dans une fen�tre � part

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 javascript :

S�lectionner tout - Visualiser dans une fen�tre � part

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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

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 javascript :

S�lectionner tout - Visualiser dans une fen�tre � part

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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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:

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.

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 � ceci

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

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 .
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 . 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 Java :

S�lectionner tout - Visualiser dans une fen�tre � part

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

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