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.