Discussion :

[SylvainPV]

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.

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.

[phildes2]

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

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.

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.

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

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

Oui

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.

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

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.

[phildes2]

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

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

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]

[Bovino]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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 ), pas uniquement les prochains.

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

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

[phildes2]

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

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 ), pas uniquement les prochains.

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

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.

[sekaijin]

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

[phildes2]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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

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 ?

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

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.

[phildes2]

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

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

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

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

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"

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.

[sekaijin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[phildes2]

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

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.

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.

[sekaijin]

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

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

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

[phildes2]

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

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[phildes2]

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

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.

[phildes2]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

[phildes2]

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