Usage des prototypes

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 ?

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

Citation:

---

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.

Citation:

---

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

Citation:

---

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.

Citation:

---

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 :

Citation:

---

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.

---

Citation:

---

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.

Citation:

---

Envoyé par SylvainPV

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é ?

retrocompatibilité ...

Citation:

---

Envoyé par SpaceFrog

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. 8-)
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 ;) ) ?

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.

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.

Citation:

---

Envoyé par SylvainPV

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.

ç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

Citation:

---

Envoyé par 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.

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 :P 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 :fleche: 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 :

Citation:

---

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.

Citation:

---

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.

---

:weird: 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 :mouarf: 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".

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.

Citation:

---

Envoyé par 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

---

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 ?

Citation:

---

Envoyé par SylvainPV

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.

Citation:

---

Envoyé par SylvainPV

Car en JavaScript :fleche: 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.

Citation:

---

Envoyé par SylvainPV

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

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

Citation:

---

Envoyé par SylvainPV

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.

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

Citation:

---

Envoyé par SylvainPV

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.

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:

---

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:

---

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

Citation:

---

Envoyé par sekaijin

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.

Citation:

---

Envoyé par sekaijin

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

Citation:

---

Envoyé par SylvainPV

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

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

Citation:

---

Envoyé par Kaamo

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.

Citation:

---

Envoyé par phildes2

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.

---

Aucune idée de quoi tu parles. J'ai beau lire de long en large l'exemple de Kaamo, je ne vois rien. En tout cas, que ce soit pour une méthode getter ou une méthode setter, this fait référence à l'objet.

Citation:

---

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.

---

Sauf que la POO sans prototype en JavaScript, ça n'existe pas... Les prototypes sont à la base du langage, il faudrait que tu comprennes ça. D'après ce que je comprends de tes explications, tu voudrais associer méthodes et propriétés à chaque instance plutôt qu'au prototype de ces instances. Ce qui fait que pour 100 objets identiques, tu vas instancier 100 fois les mêmes fonctions et variables. Non seulement c'est le pire cas possible pour l'utilisation mémoire, mais en plus on perd tout l'intérêt de la POO qui est de disposer d'interfaces communes. Ce n'est ni un fonctionnement par classes, ni un fonctionnement par prototypes, c'est juste un paquet de singletons.

Pour simplifier le discours j'écrirais "vous" pour indiquer l'usage des prototype, et 'je' pour indiquer l'absence de prototype.

Citation:

---

Envoyé par SylvainPV

Aucune idée de quoi tu parles. J'ai beau lire de long en large l'exemple de Kaamo, je ne vois rien. En tout cas, que ce soit pour une méthode getter ou une méthode setter, this fait référence à l'objet.

---

Oui, parfaitement.
Comme indiqué, je vais faire une explication circonstanciée avec exemple à l'appui.
En résumé, ce que propose Kaamo me semble très bien conçu.

Citation:

---

Envoyé par SylvainPV

Sauf que la POO sans prototype en JavaScript, ça n'existe pas... Les prototypes sont à la base du langage, il faudrait que tu comprennes ça.

---

Je me réfère à la logique, les règles que tel ou tel a défini (même si il s'agit de l'auteur) ne peuvent prévaloir sur la logique. Donc je veux, à minima, pouvoir tester d'autres voies. Et j'encourage les gens à explorer de nouvelles voies quelque soit le domaine.

Citation:

---

Envoyé par SylvainPV

D'après ce que je comprends de tes explications, tu voudrais associer méthodes et propriétés à chaque instance plutôt qu'au prototype de ces instances.

---

Oui

Citation:

---

Envoyé par SylvainPV

Ce qui fait que pour 100 objets identiques, tu vas instancier 100 fois les mêmes fonctions et variables.

---

Oui

Citation:

---

Envoyé par SylvainPV

Non seulement c'est le pire cas possible pour l'utilisation mémoire,

---

Lors d'une analyse, les contraintes techniques font l'objet d'une 'optimisation'. Cette optimisation fera peut-être appel aux prototypes (je dis cela sérieusement, je n'exclue aucune technique, je veux pouvoir les associer)

En résumé : je débute mes analyses en observant les outils qui sont à ma disposition,
ensuite je constitue des règles générales, sans m'occuper des contraintes techniques, pour essayer de créer un système cohérent,
enfin j'opère des optimisations pour répondre aux contraintes.

Citation:

---

Envoyé par SylvainPV

mais en plus on perd tout l'intérêt de la POO qui est de disposer d'interfaces communes.

---

Effectivement les 'classes' ne tiennent pas le rôle d'interface.
Sans prototype, les 'classes' servent uniquement de modèle lors de la construction. ('modèle' est un mot qui défini bien ce mode d'utilisation des classes)
Avec les prototypes, les interfaces font parti de l'objet durant toute sa vie. (j'ai bien noté ton argument avec l'exemple de la voiture)

Personnellement je n'exclue rien. Je me dis que l'un comme l'autre peut avoir son utilité. D'où mon intérêt pour l'exemple de Kaamo.
Depuis le début de ce sujet ma vision des prototypes a très nettement évolué.

Citation:

---

Envoyé par SylvainPV

Ce n'est ni un fonctionnement par classes, ni un fonctionnement par prototypes, c'est juste un paquet de singletons.

---

...qui ont une structure initiale commune.

Notes : par simplification j'écris 'objet' pour 'occurence d'objet'
Nous parlons du comportement des objets dans le runtime.

Citation:

---

Envoyé par SylvainPV

...mais en plus on perd tout l'intérêt de la POO qui est de disposer d'interfaces communes

---

Ce point est crucial pour que je comprenne bien le lien entre les prototypes est la POO.

En prérecquis, je suis d'accord avec avec l'idée d'utiliser une interface commune, puisque je les utilise comme modèle pour la construction de l'objet.

Mais dans ton exemple avec la voiture, tu m'indiques que l'objet doit aussi utiliser l'interface pour son fonctionnement
En pratique : l'objet utilisera obligatoirement une table de fonctions communes à toute sa classe.
Conséquences :
- l'accès aux fonctions est indirect, la fonction appelée sera obligatoirement le même composant (=== égalité au sens strict, dont l'adresse en mémoire est identique) pour tous les objets de la classe,
- toute modification de cette fonction sera répercutée sur tous les objets de la classe : rétrocompatibilité.

Est-ce une règle inscrite dans la définition de la POO ?

[Edit] je me rend compte que je coupe les cheveux en 4.
Effectivement les interfaces communes apportent un avantage certain à la POO.
Son absence enlèverait une liberté de choix au programmeur (mon esprit d'abstraction ne va pas plus loin que ça :roll: ).

L'exemple de Kaamo, permet de d'utiliser mes mécanismes, et sa structure semble sans faille (en conservant les niveaux d'héritage !)
Pouvez-vous m'indiquer de quand date le traitement des prototypes "en cascade" dans Javascript ?
[/Edit]

Citation:

---

pour tous les objets de la classe

---

Il faut absolument que tu arrives à te graver dans la tête qu'en JavaScript, il n'y a pas de classes !
Il est inutile de faire de la contorsion intellectuelle pour essayer de faire rentrer JavaScript dans un modèle de POO par classes car JavaScript, c'est uniquement de la POO par prototype.

Mais à part ça, oui, toutes les instances d'un prototype utiliseront une méthode commune définie dans le prototype, mais il est possible d'ajouter des méthodes à une instance spécifique ou au prototype :

Code:

---

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

var MonProto = function(){ this.foo = function(){ console.log('bar'); } }; var proto1 = new MonProto(); var proto2 = new MonProto(); proto1.foo(); proto2.foo(); proto1.bar = function(){ console.log('bar'); }; proto1.bar(); try{ proto2.bar(); } catch(e){ console.log('Non...') } try{ proto1.hello(); proto2.hello(); } catch(e){ console.log('oops !'); } MonProto.prototype.hello = function(){ console.log('World !'); } proto1.hello(); proto2.hello();

---

Enfin, si tu veux un "modèle intellectuel" pour te représenter un prototype, pense à une législation.
Si ton contrat de travail stipule que tu dois être augmenté de 1 % par an, mais qu'une loi décide que l'augmentation minimale annuelle est fixée à 1.5 %, alors, tous les contrats seront impactés (bon, on parle pas de l'aspect rétroactif d'une loi, c'est pas dans l'esprit ici :aie:), pas uniquement les prochains.

Citation:

---

de quand date le traitement des prototypes "en cascade" dans Javascript ?

---

Des origines ! Enfin... du langage, pas du monde. :mrgreen:

Citation:

---

Envoyé par Bovino

...mais il est possible d'ajouter des méthodes à une instance spécifique ou au prototype

---

Oui, javascript m'offre toutes les fonctionnalités que je désire, c'est ce qui importe. Merci pour votre exemple.

Citation:

---

Envoyé par Bovino

Enfin, si tu veux un "modèle intellectuel" pour te représenter un prototype, pense à une législation.
Si ton contrat de travail stipule que tu dois être augmenté de 1 % par an, mais qu'une loi décide que l'augmentation minimale annuelle est fixée à 1.5 %, alors, tous les contrats seront impactés (bon, on parle pas de l'aspect rétroactif d'une loi, c'est pas dans l'esprit ici :aie:), pas uniquement les prochains.

---

Merci. Cela répond exactement à ce que je demandais.

Citation:

---

Envoyé par Bovino

Il faut absolument que tu arrives à te graver dans la tête qu'en JavaScript, il n'y a pas de classes !

---

Je comprends la nécessité d'utiliser un lexique commun. Je vais faire plus attention au vocabulaire.

Les différences entre prototype et classe n'est pas un sujet que je néglige. Mais puisque ma question a trouvé sa réponse, je crains que le départ d'un nouveau sujet risque d'apporter de la confusion dans cette discussion (cf. le [edit] de mon message précédent).
Mais je vous laisse décider où et comment poursuivre cette conversation si cela est votre souhait.

Bonjour

il faut aussi comprendre que les membres d'un objet ne sont que des références (adresse en memoire)
donc lorsqu'on attache une fonction à un objet on affecte une référence.
la fonction n'existe qu'une seule fois.

A+JYT

Dans mon premier message j'affirmais, à tord, que les prototypes ralentissaient l'exécution de scripts.
Voici la raison de mon erreur : le test ci-dessous, en ligne 12, effectue une création de variable, et non pas une affectation.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

var Animal = { name:"toto", getName : function(){return this.name;}, setName : function(name){this.name=name;} }; var Chien = Object.create(Animal); var medor = Object.create(Chien);   // répété 1000000 de fois loup[i] = Object.create(Chien); loup[i].getName(); loup[i].setName("titi");

---

Explication :
En ligne 6, Animal prend le rôle de protoptype.
- Animal.toto [Edit]Animal.name[/edit] (initialisée en ligne 2) est une variable commune à toutes les instances de ce prototype
(initialisée en ligne 2) est une variable commune à toutes les instances de ce prototype

Je supposais que "return this.name" (ligne 3) accédait à la même valariable-commune que "this.name=name" (ligne 4)
Je constate qu'en lecture (ligne 3), le mot clef 'this' permet d'afficher correctement le contenue de cette variable-commune.
Par réciprocité, j'attends qu'en écriture (ligne 4), 'this' accède à cette même variable commune. J'attends à une simple modification de valeur...

Mais Javascript ne modifie pas une variable placée dans un prototype si on y accède avec 'this'. Une variable d'instance sera créée.
Mon test de vitesse est faussé car la ligne 12 déclenche la création d'une variable d'instance, qui prendra plus de temps qu'une simple écriture.

Je n'aurais pas fait cette erreur avec une fonction, et il est logique que les variables se comportent comme les fonctions...
______________________________________________________________________

Reprenons l'exemple de Kaamo, sa syntaxe est très simple, il est d'une clarté lumineuse.

Code:

---

1 2 3 4 5 6 7 8

/* Prototype Animal */ var Animal = { init: function(nom, caracsPerso, niveau) { this.nom = nom || 'Inconnu'; // si nom n'est pas renseigné : 'Inconnu' par défaut this.niveau = niveau || 1; // si niveau n'est pas renseigné : 1 par défaut this.caracs = caracsPerso || this.caracDefault; }, ...

---

Dans cet exemple, les prototypes réunissent les fonctions, elles seront donc communes aux instances utilisant ce même prototype. Elle ne seront pas dupliquées en mémoire (voir le rappel de sekaijin - post #26).
Les variables seront placées dans la table-racine de l'objet, elles seront assignées à une instance. Elle seront dupliquées en mémoire.
De plus, comme l'a précisé Bovino (post #24), ceci est une base de travail, mais cette structure nous conserve la liberté de créé des fonctions d'instance.

Evidemment la structure en cascade nous permet de conserver une mémoire des classes parents. Il est a noter que cette 'cascade' ne ralentit pas le traitement.

Merci à chacun de vous pour cette aide précieuse, et plus généralement pour tous les conseils et toutes les informations que vous apportez dans ce site.

(1) 'table-racine' : j'indique ici le premier niveau des membres d'un 'Object' repré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.

Beaucoup d'erreurs de compréhension encore...

Citation:

---

Animal.toto (initialisée en ligne 2) est une variable commune à toutes les instances de ce prototype

---

En fait c'est Animal.name ; "toto" est la valeur

Citation:

---

Je supposais que "return this.name" (ligne 3) accédait à la même valariable-commune que "this.name=name" (ligne 4)

---

C'est le cas ! Pourquoi est-ce que ça ne serait pas le cas ?

Citation:

---

Par réciprocité, j'attends qu'en écriture (ligne 4), 'this' accède à cette même variable commune. J'attends à une simple modification de valeur...

---

this fait référence à l'objet que tu es en train de manipuler. Quand tu appelles cette fonction depuis une instance nouvellement créée, elle n'a pas vocation à remplacer une propriété du prototype. Repense à l'exemple des voitures : si tu crées une voiture à partir d'un prototype et que tu veux lui donner un auto-radio, le prototype et les autres voitures créées à partir de ce prototype ne vont pas tous se voir doter d'un auto-radio. Si tu cherches à faire ça, c'est le prototype qu'il faut modifier, pas l'instance : Animal.setName("titi")

Citation:

---

Je n'aurais pas fait cette erreur avec une fonction, et il est logique que les variables se comportent comme les fonctions...

---

Les fonctions sont des variables et se comportent de la même façon que le cas précédent. Essaie de remplacer la fonction getName de medor pour renvoyer "wouf wouf" ; ce n'est pas pour autant que tes loups vont faire "wouf wouf", parce que le getName de medor aura été surchargé par rapport à sa définition dans le prototype Animal.

Citation:

---

Envoyé par SylvainPV

Beaucoup d'erreurs de compréhension encore...
Animal.toto (initialisée en ligne 2) est une variable commune à toutes les instances de ce prototype
En fait c'est Animal.name ; "toto" est la valeur

---

:mouarf: C'est une erreur d'inattention. Evidement que je veux écrire 'name'

Citation:

---

Envoyé par phildes2

... il est logique que les variables se comportent comme les fonctions...

---

Effectivement, le vocabulaire est mauvais. Pour différencier la "fonction" d'un autre type de valeur, j'ai utilisé la différence 'variable / fonction' à laquelle je suis trop habitué.
Mais je vous prie d'avoir la clémence de croire que ce n'est pas plus une erreur de compréhension que dans l'extrait ci-dessous.

Citation:

---

Envoyé par SylvainPV

...Ce qui fait que pour 100 objets identiques, tu vas instancier 100 fois les mêmes fonctions et variables...

---

Nous pouvons chercher à nous améliorer...

Citation:

---

Envoyé par SylvainPV

Les fonctions sont des variables...

---

Pour le script - var name="toto"; - je ne dirais pas qu'une constante de type String est une variable, donc je ne le dirais pas non plus pour les fonctions.
Je poserais comme postulat : les fonctions sont placées dans des variables, ou dans des slots.

Pour reformuler ma pensée, Je proposerais la correction suivante :
"Il est logiques que le comportement des variables, comme ceux des slots, ne varient pas selon le type de valeur qu'ils contiennent; que ce soient des fonctions ou des valeurs d'un autre type"

Citation:

---

Envoyé par SylvainPV

Beaucoup d'erreurs de compréhension encore...
Phildes2 : "Par réciprocité, j'attends qu'en écriture (ligne 4), 'this' accède à cette même variable commune. J'attends à une simple modification de valeur..."

---

Cela fait donc partie de votre liste des "erreurs de compréhension, encore"....
Dans mon message #27 j'ai bien précisé que mon script était erroné, et en réponse vous m'indiquez que j'ai fais un erreur... Oui, c'était précisément l'objet de ce message #27.

Comment lire le message #27 de cette même discussion ?
Je décris un test réalisé AVANT de commencer ce sujet. Je précise bien que ce test est erroné.
Il me parait naturel d'expliquer les causes de cette erreur.

Puisque cela se déroulait avant de commencer cet échange, vous retrouverez évidemment des erreurs dont vous avez parlé durant cet échange.

En résumé : oui j'ai fait une erreur,
et oui, je vais utiliser les prototypes, grâce à vos explications.

Je crois qu'une bonne lecture des théorie des languages informatiques t'aiderais beaucoup.

Une fonction est quelque chose qui existe en mémoire. (il faut bien l'exécuté)
Au même titre qu'in valeur simple ou un objet. (15, "toto")

une variable n'est qu'un nom un moyen pour le développeur de désigner quelque chose.

Code:

---

1 2 3 4

function toto() {...}; var titi = function() {...}; var test = 45; var truc = {a:12};

---

toto et titi sont deux noms qui désignent chacun une fonction qui est elle quelque part dans la mémoire. il en va de même pour test et truc qui ne sont que deux noms pour l'objet 45 ou l'objet {a:12}.

suivant le langage que tu utilises ces noms sont représenté où non en mémoire. par exemple en chaque nom va correspondre à une valeur d'address dans la mémoire. ainsi lorsque tu écris un appel commetoto(test);le compilateur mets dans le code une instruction qui copie l'adresse en mémoire de la fonction désigné par toto sur l'a pile puis il fait pareil avec l'adresse ou la valeur désigné par test et déplace le pointeur d'exécution dans la pile. il n'est là plus du tout question de toto, titi, test, ou truc. ces quatre noms on disparu lors de la compilation. le code exécutable ne contient que des adresses (offset)
(pour les puriste c'est une simplification)

pour le même code en java le compilateur va produire un bytecode. dans celui-ci les noms seront toujours présent. ils jouent le même rôle que dans le cas ci dessus. (lorsque on compile en C on peu mettre une option pour garder les nom symboliques qui fait pareil) à l'exécution JIT va traduire le bytecode en code exécutable. il va faire la même chose que pour le code C il va manipuler les adresses des objets, valeurs et functions. mais il va aussi pour chacune garder une table de correspondances nom adresse. cela permet l'introspection.

enfin avec JS le code source est analysé par l'interprète et compilé à la volé. il va comme java produire un exécutable qui manipule des adresses et des valeurs et une (des) table de correspondances nom adresses.

dans tout les cas ce qu'on appelle variable n'a de réelle existence. Ce ne sont que des nom symbolique pour faciliter la vie du développer.

on peut voir dans les langages different nom
un nom qui désigne une objet et un seul dans tout le royaume (espace de définition du langage) est dit constante. un mon qui peut désigner successivement plusieurs objets différents est dit variable.
un nom qui désigne successivement plusieurs objet l'ors de l'appel d'une fonction est dit paramètre.
et enfin un membre est un nom qui désigne une partie d'un objet.

tout cela n'est en fait qu'un ensemble de noms.

les langages langage qui gardent à l'exécution une trace de ces noms gèrent en fait une table de symbole. (nom). certain d'entre eux l'organise de façon plus ou moins rigoureuse.
par exemple dans des espaces de nom (ce qui permet d'avoir un symbole simple utilisé dans plusieurs espace)
en fonction de leur portée
en fonction de le nature (constant/variable)
en fonction du type d'objet qu'il peuvent référencer
en fonction de l'accessibilité

si on prend java il le range de cette façon. ce qui lui permet de détecter les erreur de portée à l'exécution (même si le compilateur le fait avant) de ne pas modifier une constante, de vérifier que le nom est accessible et de ne pas affecter un cochon à une variable qui référence des fruit.

en JavaScript les nom sont géré en fonction de leur porté et l'espace de nom.

A+JYT

Citation:

---

Envoyé par sekaijin

Je crois qu'une bonne lecture des théorie des languages informatiques t'aiderais beaucoup.

---

Je ne préjuge pas des compétences et connaissances de mes interlocuteurs. En fait, j'évite les à-prioris 8-)

Citation:

---

Envoyé par sekaijin

Java... mais il va aussi pour chacune garder une table de correspondances nom adresse. cela permet l'introspection.

---

Je ne m'étais pas penché sur cette partie de l'exécutable de java, merci. :D

Citation:

---

Envoyé par sekaijin

dans tout les cas ce qu'on appelle variable n'a de réelle existence. Ce ne sont que des noms symboliques pour faciliter la vie du développer

---

A l'exécution, ce nom symbolique sera, à minima, représenté par une adresse mémoire (ou un registre). "Ce qu'on appelle variable" tiens un rôle lors l'exécution.

Je vois plutôt la variable comme un couple "identifiant / valeur" (ou plusieurs valeurs successives); que cet identifiant soit une adresse mémoire (indexée ou non), une clef dans une Hashtable ou un nom symbolique.
Précision : in fine l'identifiant sera représenté par une mémoire (ou un registre) qui contient l'adresse de la valeur ou la valeur elle même.

Le nom (comme toutes les formes de l'identifiant) n'est pas la variable, pas plus que la valeur ne pourrait l'être. Ce sont 2 composants de la variables.

Citation:

---

Envoyé par phildes2

A l'exécution, ce nom symbolique sera, à minima, représenté par une adresse mémoire (ou un registre). La variable tiens un rôle lors l'exécution.

Je vois plutôt la variable comme un couple "identifiant / valeur" (ou plusieurs valeurs successives); que cet identifiant soit une adresse mémoire, une clef dans une Hashtable ou un nom symbolique.

---

Ce qui est important c'est pour la fonction. Autant on envisage facilement que pour var test = "toto"; test soit une variable qui représente l'objet "toto". Autant on a tendance à confondre fonction echo() {...} la fonction représenté par le nom echo et le nom lui même. pourtant il s'agit de la même distinction. echo est un nom symbolique au même titre que test.

la métaphore de la hashtable est particulièrement pertinente dans le cas d'EcmaScript. car le moteur utilise une représentation de ce type. et si on lance une machine virtuelle JS sous gdb on constate que le nom test et le nom echo seront traité exactement de la même façon.

je réagissais surtout à ton propos

Citation:

---

Envoyé par phildes2

Effectivement, le vocabulaire est mauvais. Pour différencier la "fonction" d'un autre type de valeur, j'ai utilisé la différence 'variable / fonction' à laquelle je suis trop habitué.

---

Ce que je voulais dire c'est que même dans les autres langages il n'y a pas de différence entre le nom d'une variable et le nom d'une fonction, le nom d'une constante. seule la nature de ce qu'ils référencent et le fait qu'ils puissent référencer plusieurs ou un seul objet change.

lorsque tu dis

Citation:

---

Envoyé par phildes2

... il est logique que les variables se comportent comme les fonctions...

---

tu confonds la fonction et son nom. dans tous les langages la variable et le nom de la fonction se comportent de la même façon. (au détail près que l'un étant une référence variable, l'autre constante)
par contre pour EcmaScript (mais aussi quelques autres langages) les éléments référencés pas ces symboles se comportent de la même façon car en JS une fonction est un objet de type "fonction" et que tout ce que référence un symbole est un objet.

A+JYT

Citation:

---

Envoyé par sekaijin

Ce qui est important c'est pour la fonction. Autant on envisage facilement que pour var test = "toto"; test soit une variable qui représente l'objet "toto". Autant on a tendance à confondre fonction echo() {...} la fonction représenté par le nom echo et le nom lui même. pourtant il s'agit de la même distinction. echo est un nom symbolique au même titre que test.

---

J'aime bien faire des tests (pas toujours réussi :aie:) pour comprendre les mécanismes.

Pour bien voir le rapport entre une 'String' et une 'Fonction' nous les placerons tout à tour dans une formule.

Code:

---

1 2	var nomImage = "myImage"; // Une String est placée dans une variable var nomPng = nomImage+".png"; // ".png" une String isolée

---

-> Nous constatons à l'évidence que la String '.png' n'est désigné par aucune variable, aucun nom n'est associé à cette String

De même une fonction pourra être placée dans une formule

Code:

---

1 2	var nomImage = "myImage"; var nomPng = nomImage+(function(name){return "."+name;})("png");

---

-> Idem, Nous constatons à l'évidence que la fonction n'est associée à aucun nom.

Si nous souhaitons associer un nom à cette fonction, nous devrons la placer dans une variable, ou dans un membre d'Objet.

Code:

---

1 2	var ext = ".png"; var toExt=function(name){return "."+name;};

---

Pour javascript, le nom symbolique sera celui d'une variable ou d'un membre d'Object.

C'est ainsi que je me suis toujours représenté l'utilisation des fonctions dans Javascript.

Important : nous ne parlons pas ici de javascript, nous parlons par exemple du C.

Citation:

---

Envoyé par sekaijin

tu confonds la fonction et son nom. dans tous les langages la variable et le nom de la fonction se comportent de la même façon.

---

cf. #32
Je ne pense pas qu'une variable se comporte comme un nom. Le nom de la variable se comporte comme un nom, mais une variable à un rôle bien défini, auquel le nom participe.

Je ne pense pas confondre.
Pas plus que je mette en doute le fonctionnement des compilateurs, car je me conforme au rôle que le compilateur donne à la suite de caractère que vous nommez "symbole". Pour le compilateur, il s'agit d'un "lexème".
Ce lexème est un identifiant, il est faux d'affirmer que tous les 'identifiants' se comportent de la même façon. En tout cas c'était faux en C.
L'analyse d'un lexème déclenche l'écriture d'une (ou d'une suite d') instruction pour traiter le composant dans sa globalité.

Nous ne travaillons pas dans un univers théorique. Il ne faut pas oublier que l'informatique est de la technique. De la pure et simple technique ! On peut définir un composant par son rôle technique.
En C, quand j'écrivais un nom de variable, je pouvais quasiment visualiser les opérations effectuées en mémoire (ce qui n'est pas très compliqué).
Par exemple : "int toto = tata;" Après compilation, "tata" représentait une adresse-mémoire ET la valeur inscrite dans cette mémoire.
Il était facile de faire un dump afin de le vérifier (J'utilise volontairement de très anciens processeurs) :
- le nom "tata" était remplacé par une instruction load (action = "lire le contenu") suivie d'une adresse mémoire.
- le nom "toto" était remplacé par une instruction store(action = "ecrire le contenu") suivie d'une adresse mémoire.
Vous constatez que la compilation des deux lexèmes représentant des variables sollicitent toujours un adresse mémoire ET son contenu.

Le point de vue technique reste à mon sens fondamental. Je lis beaucoup de théorie écrite par des gens qui en ignorent les bases techniques (ce qui n'est évidemment pas votre cas).
Ce constat m'avait incité à créer une petite machine virtuelle en vue de réaliser des tutoriels sur la "mécanique" informatique : ici
_______________

Je prends donc en compte ce que vous appelez 'symbole' en tant que "lexème". Dit de façon imagée : c'est la "face émergée" du composant que le compilateur va programmer.
_______________

Soit le script : String myVar;
- pour vous "myVar" est obligatoirement l'identifiant de la variable représenté sous sa forme symbolique
- pour moi "myVar" peut aussi représenter la variable complète, tel le fait un compilateur comme nous l'avons vu.

Soit le script : "String myVar() {}" le compilateur construira un script (très vraisemblablement une sous-routine),
Puis "myVar();" fera un appel à ce script (très vraisemblablement avec le code de l'instruction "call" suivi de l'adresse-mémoire du début de la sous-routine)

Note : remarquez que le nom de la fonction et le nom de la variable sont ici représentés par une adresse mémoire. Nous pouvons nous enhardir à y déceler une similitude. Je pense qu'il et assez facile de démontrer qu'il s'agit d'une identité de représentation technique (1)
Donc effectivement nous ne pouvons comparer que "le nom de la variable" et "le nom de la fonction".

Dans mon texte, je parlais de variables et de fonctions dont le rôle respectif, à ma connaissance, est bien différencié en C.
Important : nous ne parlons pas ici de javascript, nous parlons par exemple du C. FIN

(1) C'est cette identité de représentation technique qui est si bien traitée en Javascript
Je ne peux imaginer de comparaison entre une variable avec un nom ?
Javascript montre à l'évidence que le "nom" utilisé pour une fonction est un nom de variable. Un variable ne se réduit pas à son nom. C'est un outil composé d'un identifiant qui permet d'accéder à une valeur. Un nom tout seul ne signifie rien.
Nous constatons très facilement qu'une fonction pourra être utilisée comme valeur dans une variable. Ainsi le nom de cette variable permettra d'accéder à la fonction qui est à, ce moment de l'exécution, la valeur associée à cet identifiant.

Dans mon message précédent je montrais, pour le langage C, la similitude de la représentation, en langage machine, des identifiants pour les variables et les fonctions ,
mais je rappelais la différence de fonctionnement de ces variable et de ces fonctions,
Ensuite j'indiquais comment Javascript avait intégré la similitude de représentation des identifiants avec une exemple de fonction dans une variable.
Il ne reste qu'à vérifier les fonctionnement des variables et des slots.

Soit le script :

Code:

---

1 2 3 4

var myVar = "toto"; var myVar2 = myVar; // -> engendrera une copie de valeur, myVar = function(){alert("Hello");}; myVar(); // -> engendrera l'éxecution d'un script

---

Nous retrouvons donc, ici comme en C un différence de traitement des objets-fonction et des autres type objets :
- l'accès à une variables ou un slots associant un identifiant à un un objet fonction déclenchera l'exécution de cette fonction, comme les fonctions en C,
- l'accès à une variables ou un slots associant un identifiant à un autre type d'objet effectuera des lecture et des écritures, comme les variables en C.

Nous retrouvons ici les mêmes fonctionnements que j'ai décrit en C.
C'est l'analogie des fonctionnements qui est la cause de cette description approximative.

Citation:

---

Envoyé par phildes2

... il est logique que les variables se comportent comme les fonctions...

---

Bien je pense que nous pouvons clore le sujet.

Je rappelle donc que mon intervention initiale était basée sur un test erroné : en fait, les prototypes ne ralentissent pas le traitement.
Les causes de mes erreurs d'appréciation sont décrites dans la message dans le message #27

Suites aux remarques approprié des mes interlocuteurs, dans ce message, je pense qu'il faut remplacer : "et il est logique que les variables se comportent comme les fonctions"
par : "Il est logiques que le comportement des variables, comme ceux des slots, ne varient pas selon le type de valeur qu'ils contiennent; que ce soient des fonctions ou des valeurs d'un autre type". Indiqué dans le message #30

Je remercie toutes les membres actifs de ce forum qui m'ont apporté des informations très précieuses qui ont fait évoluer mon jugement envers les prototypes.
Je profite aussi de ce dernier message pour exprimer ma reconnaissance pour tout le travail fournit par tous les intervenants de ce site qui m'offre des informations dont j'ai besoin quotidiennement. Quel que soit la maladresse de mes propos, je conserve toujours à l'esprit que je vous dois beaucoup et cela chaque jour.

Avec ma plus chaleureuse reconnaissance.

Phillipe Destrumel