Discussion :

[phildes2]

Je me pose des questions au sujet des prototypes. Leur intervention dans un script ajoute un traitement qui selon les tests, ralentissent l'ex�cution, ou bien rec�le des dangers (cf. TypeScript).
Si d'autres m�thodes parviennent au m�me r�sultat pourquoi utiliser ce m�canisme ?

Depuis que j'utilise Javascript, je n'ai jamais eu besoin des prototypes.
J'analyses mes programme avec le concept d'objets. Dans cet esprit, je n'ai jamais eu recours aux prototypes.
La structure de base (sans prototype) de Javascript offre une palette de possibilit�s qui permet de reproduire le fonctionnement des classes-Java dont j'ai besoin.. Et m�me plus.
Note : en n'ajoutant aucune proth�se � Javascript, ce langage conserve ainsi toute sa richesse, dans un mode de fonctionnement optimum.

Les scripts que j'ai pu lire, qui faisaient appel aux prototypes, pouvaient se r��crire en les supprimant.
Je n'ai jamais rencontr� d'exemple o� les prototypes �taient indispensables.

La th�orie des prototypes est d�crite et re-d�crite un peu partout. Cette th�orie serait parfaite si elle n'entra�nait une perte de rentabilit�.
Auriez-vous des exemples 'concrets' qui n�cessiteraient obligatoirement l'usage des prototypes ?

[SylvainPV]

Hola, beaucoup de choses compl�tement fausses dans ce message. Attention � ne pas juger trop vite un paradigme que vraisemblablement tu connais mal.

Leur intervention dans un script ajoute un traitement qui selon les tests, ralentissent l'ex�cution, ou bien rec�le des dangers

Faux, les prototypes sont partout et sont la base du langage, par cons�quent il n'y a de probl�me de performance ou de s�curit� que l'on puisse imputer directement aux prototypes.

Depuis que j'utilise Javascript, je n'ai jamais eu besoin des prototypes.

Tu te sers tr�s souvent des prototypes, sans t'en rendre compte. Jamais utilis� de array.map ? de element.innerHTML ? de string.trim ? Ce sont des m�thodes et des propri�t�s issus des prototypes des objets de base en JavaScript

J'analyses mes programme avec le concept d'objets. Dans cet esprit, je n'ai jamais eu recours aux prototypes.

La programmation orient�e prototype est une forme de programmation objet, tout aussi valable que celle orient�e classes. Le truc, c'est qu'elle est m�connue et qu'elle n'est pas enseign�e dans les �coles, du coup beaucoup de gens ont en t�te que la seule fa�on de programmer fa�on objet est d'utiliser des classes.

Personnellement j'ai un avis contraire, je trouve que la programmation orient�e prototype se rapproche plus d'un mod�le objet que la programmation orient�e classes : parce qu'il n'y a pas de notion d'abstraction : tout est objet.

Pour se repr�senter les choses simplement, imagine deux usines de voitures.
La premi�re fabrique des voitures � partir de plans, un mod�le informatique avec toutes les caract�ristiques techniques, le design etc... Les plans ne constituent pas la voiture en tant que tel, ils sont abstraits, mais ils donnent toutes les informations n�cessaires pour construire les voitures. C'est le mod�le par classe.
La seconde a construit un prototype de voiture, qui reprend les fonctionnalit�s et le design d�sir�s. C'est une vraie voiture, concr�te, fonctionnelle et utilisable. L'usine construit les voitures en se calquant sur le prototype. Toutefois, il est possible de rajouter des options diff�rentes pour chaque voiture, m�me si on n'a pas mis ces fonctions sur le prototype. C'est le mod�le par prototype.

L� o� la programmation par prototypes marque clairement un point selon moi, c'est que si tu cr�es une voiture avec option autoradio � partir de la voiture prototype qui elle n'en poss�de pas, tu peux directement utiliser la voiture avec autoradio comme prototype pour une nouvelle cha�ne de fabrication. En programmation par classes, cela obligerait � faire un h�ritage de classe, et donc d'avoir de nouveaux plans abstraits et non utilisables pour la voiture avec autoradio.

Javascript offre une palette de possibilit�s qui permet de reproduire le fonctionnement des classes-Java dont j'ai besoin

C'est pour moi une �norme erreur que le tournant qu'a pris JavaScript lors de l'introduction de l'op�rateur new. On a voulu donner un simili-fonctionnement de classes avec une syntaxe qui plaise aux d�veloppeurs Java : �a a d�natur� compl�tement le JavaScript. C'est pourquoi personne ne comprend pourquoi les "classes" JS sont des fonctions, ni comment on peut retrouver une notion d'h�ritage multiple en JS. Avouons-le, c'est un bazar total et cela donne une tr�s mauvaise image du JavaScript.

Douglas CrockFord, qu'on pourrait assimiler au co-inventeur du JavaScript, a �crit cet article tr�s int�ressant : http://javascript.crockford.com/prototypal.html
Je le cite :

This indirection was intended to make the language seem more familiar to classically trained programmers, but failed to do that, as we can see from the very low opinion Java programmers have of JavaScript. JavaScript's constructor pattern did not appeal to the classical crowd. It also obscured JavaScript's true prototypal nature. As a result, there are very few programmers who know how to use the language effectively.

Auriez-vous des exemples 'concrets' qui n�cessiteraient obligatoirement l'usage des prototypes ?

Non, comme il n'existe pas d'exemples qui n�cessitent obligatoirement les classes. On parle de paradigmes de programmation, c'est-�-dire des moyens de se repr�senter et de coder plus facilement et intuitivement. La programmation objet n'a rien d'obligatoire, elle est juste plus simple. Et les prototypes sont simples eux aussi, malgr� le fait qu'on les ait travestis en classes en JavaScript.

Si toutefois tu cherches un exemple o� la programmation par prototypes montre un avantage �vident, en voici un : http://jsfiddle.net/yAa6u/
Prenons le cas d'un objet Individu qui subit des mutations al�atoires qui alternent ses propri�t�s, en les modifiant ou en cr�ant de nouvelles. L'Individu peut se reproduire, auquel cas l'enfant cr�� r�cup�re toutes les propri�t�s de son parent, mais peut subir lui aussi par la suite des modifications qui lui sont propres. En programmation par classes, �tablir un mod�le sur un sch�ma non pr�visible est un casse-t�te. On se r�soudra � faire un mod�le suffisamment g�n�rique pour qu'il englobe tous les cas possibles. Tandis qu'avec les prototypes, chaque Individu d�finit son propre mod�le tout en h�ritant des propri�t�s de son parent, autrement dit son prototype.

[phildes2]

Si toutefois tu cherches un exemple o� la programmation par prototypes montre un avantage �vident, en voici un : [/COLOR]http://jsfiddle.net/yAa6u/
Prenons le cas d'un objet Individu qui subit des mutations al�atoires qui alternent ses propri�t�s, en les modifiant ou en cr�ant de nouvelles. L'Individu peut se reproduire, auquel cas l'enfant cr�� r�cup�re toutes les propri�t�s de son parent, mais peut subir lui aussi par la suite des modifications qui lui sont propres. En programmation par classes, �tablir un mod�le sur un sch�ma non pr�visible est un casse-t�te. On se r�soudra � faire un mod�le suffisamment g�n�rique pour qu'il englobe tous les cas possibles. Tandis qu'avec les prototypes, chaque Individu d�finit son propre mod�le tout en h�ritant des propri�t�s de son parent, autrement dit son prototype.

Dans votre exemple, j'ai l'impression que si un individu subit une mutation g�n�tique apr�s la naissance de son fils, ce dernier recevra cette mutation.
Est-ce le comportement d�sir� ?

[SpaceFrog]

retrocompatibilit� ...

[phildes2]

retrocompatibilit� ...

Effectivement.
C'est pr�cis�ment un comportement des prototypes dont la pertinence est � d�montrer dans cet exemple-ci.
J'ai bien not� que le traitement par 'classe' ne serait pas pertinent.
Je laisse les possibilit�s ouvertes, je ne peux exclure une troisi�me voie.

Vous me proposez un exemple concret, ce qui r�pond exactement � ma demande, et je vous en remercie.
Gr�ce � cet exemple, je vais essayer de bien comprendre, avec le plus d'exactitude possible, le r�le et la fa�on d'utiliser les prototypes.

--------------------------------

Reprenons l'analyse dans l'ordre : �valuons les besoins, ensuite nous d�ciderons du choix de programmation le mieux adapt�.

Etape1 : �valuons les besoins
Des mutations g�n�tiques se diffusent de p�re en fils et de nouvelles mutations apparaissent � chaque g�n�ration.
Question ?
Est-il logique, qu'un fils soit affect� par une mutation g�n�tique que son p�re a subit apr�s sa naissance (la naissance du fils ) ?

[SylvainPV]

Oui, je vois o� tu veux en venir. L'exemple ne colle pas vraiment � la r�alit� des choses, vu que le parent n'est que prototype de l'enfant au moment de la procr�ation. J'ai cherch� un exemple "parlant", mais finalement ce n'est peut-�tre pas le plus appropri�. Enfin, l� o� je voulais en venir, c'est que les prototypes prennent l'avantage sur les classes dans des syst�mes non d�terministes.

[phildes2]

Avant de poursuivre je vous remercie d'avoir r�pondu � ma question. Vous �tes le seul � m'avoir proposer un exemple d'utilisaton des prototypes. J'appr�cie cet �change.

Enfin, l� o� je voulais en venir, c'est que les prototypes prennent l'avantage sur les classes dans des syst�mes non d�terministes.

Les prototypes n'ont aucun r�le dans cette gestion des syst�mes non d�terministes.

Ce sont les tableaux qui offrent cette souplesse � Javascript. L'id�e la plus ing�nieuse est de permettre d'associer un nom � chaque case d'un tableau.
Ainsi, un tableau peut tout naturellement devenir un "objet", sans aucun autre artifice. Ce tableau/objet peut donc recevoir ou perdre des 'cases'. C'est tr�s simple est tr�s efficace.

A l'inverse, les prototypes apportent de la rigidit� au m�canisme, en imposant un comportement commun � un ensemble d'objets. C'est pr�cis�ment la r�gle du traitement par 'classe'.
Les prototypes contraignent Javascript � se conformer � la loi des classes.
Cette loi semble universelle, il semble acquis que les objets seront imp�rativement assujettis � leur 'classe', leur vie durant.

La grande id�e est d'avoir fait croire � une opposition de logique entre les prototypes et les classes.
Les prototypes sont si bien "vendus" que dans votre exemple, vous leur accordez une qualit� qu'ils n'ont pas.

-----------------------

Mais il existe d'autres voies pour traiter la complexit� des objets. Je suis � la recherche de ces m�thodes alternatives.
Attention, l'objectif n'est pas de remplacer tel ou tel m�canisme par un autre. L'id�e est de toujours conserver l'esprit ouvert pour explorer d'autres voies, et d'AJOUTER des m�canismes � notre collection... afin de pouvoir choisir le mieux adapt� pour chaque usage.

Le noyau de Javascript offre une grande richesse de possibilit�s, alors profitons-en !
Si vous connaissez d'autres m�canismes de traitement des objets en Javascript, je serais heureux de les connaitre.

Merci pour votre collaboration � ce sujet.

[Kaamo]

�a me rappelle un sujet similaire il y a quelques mois :
- mon post
- mon exemple

Mais tout �a est en compl�ment de ce qu'a dit Sylvain qui a parfaitement expliqu� la chose

M�thode de danielhagnoul qui est pas mal non plus

D'ailleurs la suite de ce sujet est vraiment enrichissante. �a parle du futur proche avec Object.observe, ES6 etc

[SylvainPV]

Avant de poursuivre je vous remercie d'avoir r�pondu � ma question. Vous �tes le seul � m'avoir proposer un exemple d'utilisaton des prototypes. J'appr�cie cet �change.

Les prototypes n'ont aucun r�le dans cette gestion des syst�mes non d�terministes.

Ce sont les tableaux qui offrent cette souplesse � Javascript. L'id�e la plus ing�nieuse est de permettre d'associer un nom � chaque case d'un tableau.
Ainsi, un tableau peut tout naturellement devenir un "objet", sans aucun autre artifice. Ce tableau/objet peut donc recevoir ou perdre des 'cases'. C'est tr�s simple est tr�s efficace.

Pr�cis�ment, tu viens de transformer un mod�le que j'ai essay� de d�crire comme non d�terministe en un mod�le d�terministe en partant du postulat que toutes les mutations peuvent �tre rang�es bien gentiment dans un tableau avec des noms. Tu n'as pas tout � fait tort car comme tu le dis, les objets JavaScript sont tr�s souples et ce que tu appelles tableau (� ne pas confondre avec les Array, Map ou Set) est en r�alit� la structure de tous les objets JavaScript (ceux qui d�rivent de Object du moins, c'est � dire tout sauf les primitives). Car en JavaScript tout est objet

De ce fait, on pourrait faire un raccourci de raisonnement en disant que pour r�soudre ce probl�me avec des classes, il suffit de donner une structure d'objet � la classe d'origine, celle du patient z�ro. Pour reprendre mes propos :

On se r�soudra � faire un mod�le suffisamment g�n�rique pour qu'il englobe tous les cas possibles

Seulement, � quoi cela nous am�ne-t-il ? A des classes de plus en plus abstraites, et � l'extr�me � une classe Object. C'est pour �a que j'ai choisi cet exemple, car je trouve int�ressant le r�le des prototypes � se substituer � des singletons et des h�ritages de classe � n'en plus finir comme on devrait le faire en Java. Si j'avais port� ce code en Java, j'aurais d� d�clarer autant de classes que de patients, ou alors utiliser une classe tr�s abstraite avec un Map de g�nes, tout en �tant limit� par l'impl�mentation des Map pour les mutations.

A l'inverse, les prototypes apportent de la rigidit� au m�canisme, en imposant un comportement commun � un ensemble d'objets. C'est pr�cis�ment la r�gle du traitement par 'classe'.
Les prototypes contraignent Javascript � se conformer � la loi des classes.
Cette loi semble universelle, il semble acquis que les objets seront imp�rativement assujettis � leur 'classe', leur vie durant.
La grande id�e est d'avoir fait croire � une opposition de logique entre les prototypes et les classes.

Je ne te suis plus du tout. Le comportement commun � un ensemble d'objets, c'est la d�finition de l'objet. En quoi les prototypes sont diff�rents des classes l� dessus ? Une voiture a 4 roues et un moteur, donc quand tu manipules un objet Voiture, tu t'attends � pouvoir appeler la m�thode rouler() sans probl�mes. Ce n'est pas un "assujetissement de la loi des classes" que de ne pas pouvoir faire des voitures � deux roues, simplement la programmation objet repose sur le principe que l'on manipule des objets identifiables, et moi une voiture � deux roues �a me parle pas trop Il n'y a pas d'opposition de logique entre prototypes et classes car ce sont deux formes de programmation objet. Apr�s, on peut jouer au jeu du "qui qu'a copi� qui" mais c'est pas mon jeu pr�f�r�.

Sinon, le sujet qu'a mis en lien Kaamo est en effet tr�s complet, plusieurs intervenants ont donn� un point de vue tr�s �clair� sur ce sujet. Mais rien qui justifie le bashage gratuit des prototypes "c'est lent et pas secure".

[phildes2]

Sylvain, je vous r�pondrais ult�rieurement, ce que vous dites est tr�s int�ressant, je tiens � prendre le temps de bien vous lire.

�a me rappelle un sujet similaire il y a quelques mois :
- mon post
- mon exemple

Mais tout �a est en compl�ment de ce qu'a dit Sylvain qui a parfaitement expliqu� la chose

Je suis impressionn� !

Il y a effectivement des �volutions surprenantes dans le javascript.
Je reste septique d'un point de vue th�orique, mais soyons pratique, cela n'est pas tr�s important vue les possibilit�s techniques propos�es dans vos exemples.

Effectivement, votre exemple est tr�s marquant !
Je suis r�ellement surpris par la vitesse d'ex�cution (je me suis amus� � lui faire des mis�res, mais �a ne l'a pas perturb�) Evidemment l'acc�s � une table simple (pas d'arborescence) reste plus rapide sur la plupart des navigateurs. Mais vu la vitesse, ce ralentissement n'a rien de p�nalisant. Sauf avec l'Explorateur Windows qui reste le plus poussif sur ma machine.

Les comportements sont coh�rents, je retrouve les fonctionnements qui me sont chers. Il reste � faire quelques v�rifications, mais 'vos' prototypes semblent r�agir aussi bien que mes outils qui ne traitent qu'une table.
J'ai commenc� � lire votre sujet et les liens que vous indiquez. Merci pour toutes ces informations.

Je reviendrais peut-�tre pour demander des pr�cisions.

Ah si, je reste toujours sur ma faim au sujet de la retrocompatibilit�. Pouvez vous me donner des exemples concrets o� cela est utile ?

[phildes2]

ce que tu appelles tableau...

Pr�cision : c'est une repr�sentation purement 'm�canique', qui pourrait se rappocher de l'id�e d'un tableau d'adresse en langage machine, que l'on traduirait en C par "tableau de pointeurs".
Je ne pr�juge pas du r�le des composants et ne leur impose aucune r�gle, �-priori.

Car en JavaScript tout est objet

Je pr�f�re, dans un premier temps, rester sur une vision que je d�finis comme 'm�canique'. Voir ci-dessus.

Je ne te suis plus du tout. Le comportement commun � un ensemble d'objets, c'est la d�finition de l'objet

Les 'types' d�finissent un mode d'acc�s aux composants de l'objet, aux attributs ou aux m�thode. Mais une m�thode peut �voluer et son traitement peut �tre modifi� en cours d'ex�cution. Cet objet vit sa vie ind�pendemment des autres objets de la m�me classe.
Du reste le traitement par prototypes autorisent cette modification de comportement pour un objet pr�cis, ind�pendamment de sa famille.
http://leroux.andre.free.fr/reliant.htm

Avant de poursuivre je souhaiterais savoir si nous sommes en accord sur ces 2 points.
- autoriser l'analyse des fonctionnalit�s de Javascript avec ce que je nomme une vision "m�canique" (cela n'exclue pas une �tude s�mantique, mais bien s�parer les 2 types d'analyse)
- le comportement d'une occurence d'objet peut �voluer et se diff�rencier des autres objets de m�me type.

[SylvainPV]

Si tu fais r�f�rence � l'impl�mentation par les moteurs d'ex�cution JavaScript, je ne m'y connais pas du tout. Je me contente de faire quelques jsperf de temps en temps pour voir si telle mani�re de faire est plus performante qu'une autre. Dans mon travail, la performance est plus une contrainte qu'un objectif en soi. J'imagine que plus on travaille avec des modes de conception "haut niveau", plus il est difficile d'optimiser les performances. C'est l'argument le plus courant que nous rab�che les devs C/C++ : http://www.csjournals.com/IJCSC/PDF1-2/9..pdf ; TLDR: l'objet c'est bien beau mais c'est mal optimis�. Oui, ils ont sans doute raison, je pense que l'on se creuse davantage les neurones en codant de mani�re proc�durale ; mais bon, l'objet �a aide pas mal pour y voir clair dans un code parfois...

[phildes2]

Si tu fais r�f�rence � l'impl�mentation par les moteurs d'ex�cution JavaScript

Non, je pense � la fa�on dont les objets sont affich�s dans la liste des variables dans le d�bugger Javascript

C'est une repr�sentation sch�matique produite par les propres programmeurs qui ont install�s Javascript dans le navigateur.

[SylvainPV]

Ah, alors je n'ai pas d� comprendre o� tu voulais en venir.

[phildes2]

mais bon, l'objet �a aide pas mal pour y voir clair dans un code parfois...
...
Ah, alors je n'ai pas d� comprendre o� tu voulais en venir.

Que nous discutions sans id�e pr�con�ue sur son interlocuteur. Ai-je indiqu� que je n'utilisais pas d'objets ?

Je d�veloppe en POO.

[sekaijin]

Je suis d'accord avec Sylvain sur sa comparaison entre les usines de voitures.

� l'usage on peux regarder la chose sous une autre approche.

si on prends le mod�le C++ le d�velopper cr�� des classes et donne des instructions pour les instancier.
le compilateur g�n�re des structures pour les objets en se basant sur le mod�le de classes.

Pour faire simple on peut dire qu'une instance d'un objet est une structure (au sans struct C) qui est faite de valeurs et de pointeurs+ � cela s'ajoute un pointeur sur un tableau. ce tableau est lui une liste de pointeur sur les m�thodes applicable � l'objet.

avec une telle repr�sentation la classe n'existe pas dans la m�moire au moment de l'ex�cution. existent seulement des constructeurs des destructeurs et des m�thodes.

dans cette approche la classe n'existe que lors de la compilation.

Avec le mod�le Java on change d'approche. le d�veloppeur tout comme en C++ cr�� des classes et donne des instructions pour les instancier. le compilateur g�n�re une repr�sentation de la classe qui sera pr�sente en m�moire lors de l'ex�cution. l'instance d'un objet devient alors un ensemble de valeurs et de pointeurs. plus une r�f�rence � sa classe.

imaginons maintenant que nous conservions le fonctionnement de Java mais que nous autorisions la modification de la classe au runtime. la structure repr�sentant la classe en m�moire en serait chang�e. tous les objet instanci� � partir de cette classe ayant une r�f�rence � la classe h�riteraient instantan�ment de cette modification.

EcmaScript offre cette possibilit�. on voit bien que ce n'est pas propre � la POO orient� prototype. (on vient de la d�crire sur des classes)

En se penchant un peut plus pr�s de java on vient de voir que la classe �tait repr�sent� en m�moire. Mais le langage ne permets pas de manipuler cette structure.
si nous envisagions de le permettre il faudrait savoir comment est faite cette repr�sentation. pour rester homog�ne on pourrait imaginer une classe Class dont toutes les classes d�riveraient. en respectant la hi�rarchie java on aurait alors la class Class h�ritant de la class Object. une classe serait alors une instance de la classe Class donc un objet � part enti�re.
ceux qui se sont pench� sur l'introspection en Java doivent entrevoir la chose.
Finalement dans une telle approche il nous semblerait naturel qu'une classe soit un objet comme un autre et que nous puissions le manipuler. il ne serait alors pas aberrant de demander � une classe via un m�thode de retourner une instance.
avec lAPI reflexion on fait

Code java :

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

1
2
Constructor<?> constructor = Class.forName("com.journaldev.reflection.ConcreteClass").getConstructor(int.class);
Object myObj = constructor.newInstance(10);

Si on avait un vrais objet on pourrait �crire

Code java :

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

Object myObj = com.journaldev.reflection.ConcreteClass.newInstance(10);

Ceci montre qu'un langage � base de classe peut tout aussi bien �tre dynamique. Ce genre de langage existe.
si on se penche sur ce genre de langage la notion de classe est conserv�e mais finalement c'est le constructeur qui est au centre du fonctionnement de la POO. c'est en effet lui qui cr�e les objets et c'est lui qui cr�e le lien entre l'instance et l'objet qui lui sert de classe.

La diff�rence fondamentale avec la POO � base de prototype est l�. la POO � base de prototype supprime la notion de class. pour cela tout deviens objet. que ce soit une valeur, une m�thode, ou une structure.
une fonction �tant un objet et le constructeur �tant une fonction il n'est plus n�cessaire de conserver l'objet class, l'objet constructeur est capable de porter toute la d�finition du mod�le.

reste le fait qu'en JavaScript on peut ajouter modifier supprimer des membres � un objet sans tenir compte de sont constructeur. (surcharge sur les objets)

L� encore on peut revenir � la repr�sentation en m�moire d'un objet.
en C++ toujours en faisant simple une instance est une struct. les membres sont rep�r� par le compilateur par un d�placement d'offset � partir de la base de l'objet.
supposons que nous ayons un objet dont le membre a est une structure de type B. en m�moire nous aurons � la position x de l'objet un pointeur vers une instance de structure B. avec une telle repr�sentation on voit vite que l'on peu facilement � l'ex�cution modifier ce pointeur pour r�f�rencer une instance d'un type C.
Il est evident qu'il va falloir �tre prudent pour la suite.

PHP � choisi de representer se objet sous une forme semblable mais l�g�rement diff�rente. � la place d'une structure simple PHP utilise une HashMap. du coup il conserve � l'ex�cution le nom des membre. mais offre au passage la possibilit� d'ajouter des membres.

l� encore on voit qu'ajouter ou supprimer des membres dynamiquement est � la port� de langage � base de classes.

EcmaScript offre donc une approche ou tout est objet, un objet �tant repr�sent� en m�moire par une HasMap

une modification dynamique d'un prototype n'est finalement que l'ajout, la suppression, ou la modification d'un pointeur dans une HashMap. question performance l'impact est null.

mais il y a un b�mol. avec JavaScript. JavaScript c'est EcmaScript plus des objets du W3C. ces objet ne sont pas des objet JS mais des instances d'objet ou de structures dans le langage compil� du navigateur. (en g�n�ral C++) le prototype de ces objets l� est une passerelle entre le monde EcmaScript et C++
modifier un tel prototype est plus complexe. en effet le prototye en question bien qu'�tant un objet JS il ne peux pas modifier la partie C++ et donc lorsque une modification du prototype intervient il faut v�rifier � chaque appel si on doit utiliser la m�thode ou le membre natif ou une �ventuelle version modifi�e.

c'est pour cette raison que la plus part des lib qui modifiait les prototype des objets natif sont revenu en arri�re. dans ce cas l� il est pr�f�rable de modifier les instances que le prototype.

A+JYT

[SylvainPV]

c'est pour cette raison que la plus part des lib qui modifiait les prototype des objets natif sont revenu en arri�re. dans ce cas l� il est pr�f�rable de modifier les instances que le prototype.

Pendant un temps, on modifiait les instances car IE7 n'exposait pas dans le scope global les objets Node, HTMLElement etc... Mais �a ne r�sout pas le probl�me de fond : lorsque l'on �tend un objet dont on est pas propri�taire, on s'expose � d'�ventuels conflits avec d'autres biblioth�ques ou de futures sp�cifications. C'est aussi pour �a que les biblioth�ques doivent �viter d'exposer trop de variables globales, voire pas du tout avec une d�claration UMD.

[phildes2]

� l'usage on peux regarder la chose sous une autre approche.

Merci pour cette description claire et circonstanci�es de l'�volution du traitement des classes.

Si vous l'acceptez, je souhaiterais placer ce texte dans mon forum. Je voudrais le mettre en forme et ajouter quelques pr�cisions apr�s v�rification (notamment pour le C++, c'est loin tout �a), mais je ne le rendrais plublic que sous votre contr�le.

Mais rien qui justifie le bashage gratuit des prototypes "c'est lent et ou pas secure".

A - Voici des tests en utilisant la m�thode 'create()' indiqu�e sur les sites : developer.mozilla et wikipedia.org

1 - create() + variable plac�e dans un parent (prototype) de l'objet: dans Animal
test de vitesse avec variable dans prototype

2 - create() + variable plac�e dans l'objet ('ownProterty') : loups[n]
test de vitesse avec variable dans l'objet

B - Avec l'usage de 'new' indiqu�e dans developer.mozilla et developpez.com

3 - avec prototype + new() + variable plac�e dans l'objet ('ownProterty')
test de vitesse avec prototype + l'instruction new + variable dans l'objet

si la variable est plac�e dans le parent, la vitesse en sera affect�e comme pour les objets construits avec 'create()'

C - M�thode ancestrale, sans prototype
(notez que vous pouvez remplacer 'init( this )' par 'call( this )', placez le corps de 'init()' dans le corps de 'Animal', 'this_' devient 'this')

4 - sans prototype + new() + variable plac�e dans le parent
test de vitesse sans prototype avec l'instruction new + variable parent

[Kaamo]

Pour info, les jsfiddle n'affichent rien. (j'ai une erreur 500)

[phildes2]

Pour info, les jsfiddle n'affichent rien. (j'ai une erreur 500)

Je vais recopier les scripts, d�s que possible.

Mais avant je vous pr�cise que cette liste de test est incompl�te car je voulais isoler les erreurs qui m'ont amen� � penser que le traitement des prototypes �tait plus lent.

Evidemment, comme je l'ai d�j� �crit votre script retient mon attention. Apr�s quelques v�rifications, j'ai pr�vu de poster votre exemple � la suite de ce sujet. Il d�montre fort bien le pi�ge dans lequel je suis sottement tomb�.
J'esp�rais na�vement que les prototypes �taient assez bien organis�s pour affecter au 'this' le m�me r�le en lecture et en �criture. Probl�me de logique des prototypes qui, � l'�vidence ne vous a pas �chapp�, puisque vous y rem�diez.

Ensuite, j'indiquerais ce sujet comme 'r�solu'.

Je suis trop habitu� � la POO sans prototype dans javascript. Elle propose une programmation intuitive qui �vite pr�cis�ment cette complexit�. Puisque sans prototype, les fonctions accompagnent les donn�es dans la table-racine(1) de l'objet -> le pointeur 'this' d'une fonction reste toujours associ� aux variables d�crites dans l'Object de cette fonction.

(1) 'table-racine' : j'indique ici le premier niveau des membres d'un 'Object' rep�sent� dans les d�buggers de Javascript. C'est un tableau compos� d'�l�ments accessibles par leur identit� (nom), ce que sekaijin nous d�crit comme une Hashtable.