Variable static et prototype

Bonjour,
Si je veux déclarer une variable de type static, je peux le faire dans le corps de définition de la fonction (comme pour x).
Je peux aussi déclarer une variable dans le prototype (comme pour y).
Quel est l'intérêt d'une méthode par rapport à l'autre ?
(à part que dans le second cas il me faut un objet pour y accéder, donc un peu moins pratique peut-être...)

Code:

---

1 2 3 4 5 6

function maClasse{ arguments.callee.x=0; } maClasse.prototype={ y:0 };

---

Non, ce n'est pas tout à fait la même chose. arguments.callee peut ici être remplacé par maClasse, donc x est une propriété de la fonction maClasse. Tandis que y est une propriété du prototype de maClasse. La différence majeure est que si l'on construit une instance avec le constructeur maClasse: var monInstance = new maClasse(); ; l'instance héritera des propriétés du prototype de maClasse mais pas des propriétés de maClasse directement. Donc monInstance.y sera défini mais pas monInstance.x. Aussi, si tu modifies la propriété y d'une instance, celle du prototype ne sera pas modifiée ; donc y n'est pas une propriété statique.

Si on prend la définition Java d'une variable statique, à savoir partagée par toutes les instances d'une même classe, alors en JavaScript il suffit d'attacher cette propriété à une portée parente. Il peut s'agir de la fonction constructeur comme tu l'as fait avec x, mais on peut aussi prendre n'importe quelle variable de portée parente, locale ou globale :

Code:

---

1 2 3 4 5 6 7 8 9

var compteur = 0; //variable locale statique function maClasse{ arguments.callee.x=0; compteur++; } maClasse.prototype={ y:0 }; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10

window.compteurMaClasse = 0; //variable globale statique function maClasse{ arguments.callee.x=0; window.compteurMaClasse++; } maClasse.prototype={ y:0 }; };

---

Tu as raison. Il y a donc copie du prototype pour chaque instanciation. Je voyais plutôt un hash "partagé"...
Donc il est préférable d'éviter d'y inclure autre chose que des fonctions.
Autant pour moi ! :oops:
La question que je me pose en conséquence, c'est est-ce-que si j'ai beaucoup d'instances, il n'est pas préférable de stocker les méthodes de la classe ailleurs que dans le prototype et d'appeler
uneMethode.call(this,...);
au lieu de
this.uneMethode(...);
Au niveau de la mémoire, c'est sans doute mieux...

En fait, lorsqu'on souhaite récupérer une propriété d'un objet, si celle-ci n'est pas trouvée dans l'objet, on regarde dans le prototype de l'objet et le prototype de ce prototype etc... ça s'appelle remonter la chaîne prototypale. Donc c'est bien un partage, tant que la propriété n'a pas été modifiée spécifiquement pour l'instance. Vérification:

Code:

---

1 2 3 4 5 6 7 8

function maClasse(){ arguments.callee.x=0;}maClasse.prototype={ y:0};   var monInstance2 = new maClasse(); monInstance.y; // == 0, y récupéré depuis le prototype Object.keys(monInstance); // == [] array vide, monInstance n'a pas de propriétés non héritées monInstance.y+=1; //1, on modifie une propriété du prototype qui du coup devient une propriété propre à monInstance Object.keys(monInstance); // == ["y"]

---

Ceci dit rien ne t'empêche de mettre autre chose que des fonctions dans le prototype, c'est comme ça qu'on fait de l'héritage en JavaScript. En Java on distingue les classes et les interfaces, mais en JavaScript tout est objet (et je trouve ça personnellement bien plus simple bien que ça déconcerte beaucoup de devs venant d'autres langages)

Pour l'histoire de la mémoire, non ça ne change quasiment rien. Mieux vaut mettre les propriétés dans le prototype: ça rejoint davantage le principe de programmation objet et ça permet aux méthodes d'accompagner l'objet ; on est pas obligés de s'assurer qu'elles sont toujours à portée et de les appeler avec .call

Ma réponse est un peu tardive, fêtes obligent...