Discussion :

[Hibou57]

Hallo ragazo/ragaza,

J'ai quelques doutes quand à la possibilité de trouver une réponse claire à cette question, parce qu'évidement les navigateurs ne se comportent certainement pas tous de la même manière. Mais peut-être certaines personnes auront-elles aux moins des informations valables pour InternetExplorer.

La question :
Un « constructeur » peut attacher une « méthode » à un « objet » de deux manières (je met tout entre guillemet... parce que franchement qui oserait dire que JavaScript est un labgage orienté objet ?).

Sans ordre de préférences, les deux manières de faire sont les suivantes.

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
 
function Class ()
{
   this.method = method;
   function method ()
   {
      // The method code comes here
   }
}

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
10
 
function Class ()
{
   this.method = Class_method;
}
 
function Class_method ()
{
   // The method code comes here
}

J'ai personnellement une préférence pour la première manière de faire (inutile d'en donner les raisons ici). Mais je me demande si elle présente oui ou non des risque de consomation de mémoire inutile. En clair : est-ce que le code de la méthode sera dupliqué autant de fois que d'objets seront créés ? Bien sûr, la méthode restera toujours attacher par référence : mais le navigateur va t-il à chaque fois donner une référence à une copie du code ou donnera t-il une référence à une seule instance du code ?

Pensez au cas où de nombreux « objets » sont créés ....

Cette question venant bien sûr dans le soucis d'économie de la mémoire ...

Award (récompense) : la reconnaissance de la communauté developpez.net à toutes personnes qui aurait des informations fiables sur ce délit de gaspillage potentiel.

P.S. Pas terrible la nouvelle manière d'afficher les section de code sur le forum : sur IE, la boite de code est deux fois plus large que le code lui-même... pas fameux C'était bien mieux comme c'était avant

[javatwister]

pas de réponse définitive, mais il semble bien que le prototypage évite la répétition d'une recherche de méthodes pour chaque objet:

Code :

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

1
2
3
4
5
6
7
8
9
function Class (){
//  définitions
}
 
function Class_method (){
// méthode à affecter aux objets Class
}
 
Class.prototype.method=Class_method;

[Hibou57]

Gracias JavaDancer ... heuuuu.. (je fais encore l'imbécile)

pas de réponse définitive, mais il semble bien que le prototypage évite la répétition d'une recherche de méthodes pour chaque objet

Répétition d'une recherche ? Quelle recherche ? Je pensais naïvement que les navigateurs ajoutent un membre à l'objet, et qu'à ce membre est assigné une référence à la méthode, et que donc l'appel est direct. Ce n'est pas comme ça que ça se passe ?

Dis moi, tu as l'air de connaître des choses trés interessantes que j'aimerais bien savoir moi aussi.

Code :

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

1
2
3
4
5
6
7
8
9
function Class (){
//  définitions
}
 
function Class_method (){
// méthode à affecter aux objets Class
}
 
Class.prototype.method=Class_method;

Petite parenthèse préalable : je n'utilise habituellement pas le prototypage (même si j'en connais l'existance), parce que j'utilise autant que possible des méthodes basiques, et je ne suis pas certains que le prototypage fonctionne bien partout.... tout ça pour dire que je ne connais pas cette question en profondeur, mais je peux faire quelques remarques tout-de-même.

La cible du prototypage, n'est bien sûr pas la fonction elle-même, mais est plutôt une référence à ce qui a créé l'objet. C'est-à-dire qu'apparement c'est une sorte de pseudo classe -- au moins dans le cas où il n'y a qu'un seul constructeur (j'y reviens plus loin).

Donc on a une sorte d'objet, qui fait référence à l'origine commune de tout les objet créé par ce constructeur. Cet objet contient des références aux méthodes, et les objet contiennent chacun une référence ver cet objet. Il y a donc une indirection lors de l'appel, ce qui le rend légérement plus long, mais en même temps, il y a effectivement logiquement économie de mémoire. Pas économie au niveau du stockage des méthodes, mais économie au niveau du stockage des références au méthodes, car celles-ci sont factorisé dans un seules objet. Chaque objet, au lieu d'avoir des références vers toutes les méthode, n'aura qu'un référence vers cet objet, qui finalement contiendra les références vers les méthodes. D'un certaine manière, cet objet fonctionne la TMV -- Table des Méthodes Virtuelles -- des langages à objet.

C'est donc un premier pas vers l'économie.

Mais une question ma chatouille : bien que JavaScript ne connaisse pas le typage, le typage y existe tout de même conceptuellement dans l'esprit du/de-la developpeur(se), et on peut donc tout de même y parler de typage. Et il se trouve qu'un type peut avoir plusieurs constructeur. Donc il faut prototyper tout les constructeur. Si lors d'une réutilisation de code, un nouveau constructeur est créé, alors il faudra donc le prototyper lui-aussi. Mais il se peut que des prototypages soient oubliés ou même que certains ne soient pas connus. C'est donc une source d'erreur. Le risque d'erreur provient de la délocalisation du prototypage, qui peut se produire n'importe où dans le code, et donc être partitiellement invisible à qui réutilise un code.

J'y vois bien une solution -- que je ne donne pas tout de suite -- mais elle nécéssiterait que la cible du prototypage puisse être une référence à un constructeur, et non pas seulement un identificateur de constructeur.

Peut-on faire par exemple

Code JavaScript :

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

1
2
3
4
5
6
7
8
 
var C;
function Truc ()
{
   // Any code
}
C = Truc;
C.prototype.method = ....;

Est-ce autorisé ?

Bon, au moins c'est vrai que le prototypage semble garantirles risques de duplication du code.

[javatwister]

pour ne répondre qu'à ta dernière question, oui,

Code :

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

C.prototype.method = ....;

est une déclaration valable;


pour le reste, j'attends que passe ma migraine...
en tout cas (même si c'est hors-sujet), tu peux être sûr que si à la ligne suivante, tu déclares un nouvel objet Truc() et que tu demandes

Code :

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

monTruc.method();

tu bénéficieras de ladite méthode;

[gKsam]

J'utilise très peu le prototypage. Mais j'utilise beaucoup cette façon là :

Code :

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

1
2
3
4
5
6
7
8
9
function Class ()
{
   this.method = Class_method;
}
 
function Class_method ()
{
   // The method code comes here
}

Je ne me suis pas encore très intéressé à cela. Si tu veux regarder comment je fait, je crois que la meilleur méthode c'est de récupérer ma fonctiothèques
içi

Je vais y regarder de plus près aussi car cela m'intéresse aussi. Ce n'est pas parce que c'est du côté client que l'on ne doit pas optimiser le fonctionnement.

[Hibou57]

Ce n'est pas parce que c'est du côté client que l'on ne doit pas optimiser le fonctionnement.

Je dirais même plus : c'est parce que c'est du côté client que l'on doit optimiser le fonctionnement.

@JavaTwister: moi aussi j'ai la migraine en ce moment... mais j'espère qu'elle passera dans le week-end

[gKsam]

J'ai trouvé quelque chose. Mais pour javascript.

http://developer.mozilla.org/fr/docs...Core:Fonctions
au paragraphe "Question de performance"

Je n'ai rien trouvé pour le JScript sur le site de msdn sur cette histoire de performance

Ouf! j'utilise la méthode la plus rapide. Ce n'est pas celle que tu utilises

Sur ce coups là on est encore inversé...

[Hibou57]

Sur ce coups là on est encore inversé...

Bohh, ... c'est pas systématique non-plus... à moins que tu n'ai eu des avis non-exprimés sur certains de mes posts et dont je n'aurais donc pas connaissance.

Comme cela n'est pas très performant, il est conseillé d'éviter les fermetures autant que possible, c'est-à-dire d'éviter d'imbriquer des fonctions.

Avertissement:
Précision importante à toutes les personnes qui auront lu cela : il n'est absoluement pas question des fonctions imbriquées pour des raisons de portées et d'organisation du code.

Par exemple cette contre-indication ne s'applique absoluement pas à ceci :

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
 
function a ()
{
   function b ()
   {
      // Some code.
   }
   // Some code invocking b().
}

Car dans ce cas aucune référence à b n'est renvoyé à l'extérieur. Vous pouvez donc continuer à utiliser les fonctions imbriquées au sens traditionelle du terme, car elles facilitent la lecture et la maintenance du code en évitant de surcharger inutilement l'espace globale (c'est entre autre justement parce qu'ils interdisent les fonctions locales, que les langages C et C++ sont de si mauvais langages).

Par contre, il faudra logiquement éviter d'utiliser des constructeurs déclarés comme fonctions imbriquées. Par exemple

Code JavaScript :

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

1
2
3
4
5
6
7
8
9
10
11
 
function a ()
{
   var o;
   function Constructor ()
   {
      // Some code.
   }
   o = new Constructor();
   return o;
}

Ici, si le navigateur supporte le prototypage, il sera obligé de conserver une référence à Constructor, et ne libérera donc pas le contexte de « function a () ».

Une remarque à contre-pied de gkSam :
Ce problème est tout de même un problème de conception du navigateur, car rien n'impose à un navigateur de garder vivant le contexte d'une fonction renvoyant des références à une fonction interne. Un navigateur raisonnablement intelligent, devrait être tout à fait capable de determiner que la fonction local ne dépend pas du contexte de la fonction mère, et pourrait alors rendre externe la fonction interne, et la placer virtuellement dans le contexte globale.

At this point, FireFox/Gecko seems a bit weak And indeed, FireFox's memory leaks are frequent...

Qu'en est-il maintenant d'InternetExplorer ?

[gKsam]

Qu'en est-il maintenant d'InternetExplorer ?

Un début de réponse...

Je suis sous linux (debian). J'ai donc testé via le moniteur système.

Résultat sur cette discussion rechargée plusieurs fois:

Firefox (chez moi iceweasel) : la mémoire gonfle au fur et à mesure et cela prend pas mal de temps processeur.

Internet explorer 5, Internet explorer 5.5 et Internet explorer 6 (avec wine) : La mémoire reste stable et cela ne prend pas autant de temps processeur. De plus, au bon d'un certain temps, sauf pour IE5. La mémoire est libérée.

Bilan : Sur ce coups là, Internet Explorer est plus efficace. Il prend moins de temps processeur et libère la mémoire. Quand à firefox, la mémoire n'est jamais libérée et il consomme plus de temps processeur.

Ce n'est pas le meilleur test mais cela donne une petite idée.

Pour le coups de l'inversion :

Bohh, ... c'est pas systématique non-plus... à moins que tu n'ai eu des avis non-exprimés sur certains de mes posts et dont je n'aurais donc pas connaissance.

C'est vrai que je me suis un peu emballé. Pour deux fois, j'en fais une généralité. encore désolé.

[gKsam]

Après recherche (5 minutes) je suis tombé sur ça

après avoir fait les modifications la mémoire utilisé par firefox reste stable et ne gonfle plus à outrance.

Comme d'habitude tout est question de choix : http://standblog.org/blog/post/2006/...-info-ou-intox

Apparemment, c'est pour afficher plus rapidement les pages déjà chargées que la mémoire prend beaucoup de place... (bouton précédent et suivant)

[Hibou57]

Hallo,

Tu m'a surpris, je ne m'attendais pas à un tel teste. C'est vraiment gentil

.... quand tu y va, tu ne fais pas les choses à moitié toi (comme dev tu m'inspire bien confiance)

Un début de réponse...

Je suis sous linux (debian). J'ai donc testé via le moniteur système.

Résultat sur cette discussion rechargée plusieurs fois:

Firefox (chez moi iceweasel) : la mémoire gonfle au fur et à mesure et cela prend pas mal de temps processeur.

Internet explorer 5, Internet explorer 5.5 et Internet explorer 6 (avec wine) : La mémoire reste stable et cela ne prend pas autant de temps processeur. De plus, au bon d'un certain temps, sauf pour IE5. La mémoire est libérée.

Bilan : Sur ce coups là, Internet Explorer est plus efficace. Il prend moins de temps processeur et libère la mémoire. Quand à firefox, la mémoire n'est jamais libérée et il consomme plus de temps processeur.

Je n'ai pas Linux, mais j'ai fait le teste d'une autre manière depuis longtemps : utilisation de FireFox sur les machines à faibles resources -- 48M RAM dans mon cas --, et là c'est la saturation permanente de la mémoire virtuelle. Ce teste est imprécis, mais c'est un teste concrêt.

Je n'ai pas encore reçu mon nouveau PC, alors j'ai envie d'abuser un peu de toi en te demandant si tu as aussi la possibilité de tester Opéra 9 dans les mêmes conditions. D'expérience, je dirais qu'Opéra est meilleure que FireFox pour la gestion de la mémoire, mais pas aussi bon que IE. Mais quand je dis pas aussi bon que IE j'ai un doute, parce bien que je constate qu'il consomme plus au démarrage que IE, cela ne signifie pas qu'en fonctionnement il accrois plus sa consomation que ne le ferait IE dans les même condition.

Merci pour le teste (IE vs FF).... et puis promis, quand j'aurai mon nouv. PC, j'installe Linux en dual boot

P.S. Pour la petite boutade, non, tu n'as pas exagéré, c'est moi... je sais bien qu'on est fréquement pas d'accord sur certaines choses

[FremyCompany]

La version prototype est de TRES loin la version
1) La plus rapide
2) La moins couteuse en mémoire
3) La moins facile à imaginer pour un développeur qui vient d'un language objet non-POOL (Prototyped Object Oriented Language ou Language Orienté Prototype d'object)

La solution de second choix est

Code :

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

1
2
function O() { this.func = O_func; }
function O_func() {}

La dernière solution

Code :

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

1
2
3
function O() {
  this.func = function o_func() {};
}

est à banir.

_______________________________________________
Le code suivant est aussi à banir, lorsque cela est possible, car il consomme plus de mémoire/processeur, contrairement à ce que l'intervention d'avant tend à dire :

Code :

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

1
2
3
4
5
6
function a() {
  function b() { ... }
  ...
  k = b()
  ...
}

que

Code :

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

1
2
3
4
5
6
function b() { ... }
function a() {
  ...
  k = b()
  ...
}

[javatwister]

ouf
t'arrives à temps

[gKsam]

Ouf!

C'est comme ça que je développe en javascript.

J'utilise très peu la méthode pas cool.

Merci, FremyCompany pour cette petite synthèse.

[Shinuza]

Hum, il me semble que vous oubliez les méthodes de Prototype et Mootools.

[Hibou57]

La dernière solution

Code :

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

1
2
3
function O() {
  this.func = function o_func() {};
}

est à banir.

Sauf que cette technique est utilisée pour simuler les méthodes privées..... et pas que chez les débutant(e)s.... mais bon, vrai que ça peut se légiferer.

La boulette est là :

Le code suivant est aussi à banir, lorsque cela est possible, car il consomme plus de mémoire/processeur, contrairement à ce que l'intervention d'avant tend à dire :

Code :

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

1
2
3
4
5
6
function a() {
  function b() { ... }
  ...
  k = b()
  ...
}

que

Code :

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

1
2
3
4
5
6
function b() { ... }
function a() {
  ...
  k = b()
  ...
}

Si tu n'aime pas les fonctions imbriquées, c'est ton choix, mais ça me semble difficile de prétendre qu'il faut les éviter. C'est même un bon point du langage.

Maintenant il y a fonction et fonction, et il faut aussi voir la fréquence d'appel. Parce qu'il ne faut pas oublier qu'on agit pas sur une chose isolée, mais sur un tout, et qu'au moment d'évaluer une modification, il faut mettre en balance tous les effets. Et se priver de l'imbrication des fonctions pour gagner 10 instructions CPU, je n'en vois pas l'intérêt, même sur une vieille machine comme la mienne.

Je crois que c'est vraiment la dernière chose à dire au personnes qui apprennent JavaScript : ne pas utiliser les fonctions imbriquées.... c'est vraiment la dernière chose à leur dire.... surtout quand la justification repose sur l'implémentation plus ou moins heureuse de tel ou tel navigateur.

Alors tu veux apprendre aux gens à ne pas utiliser les méthodes imbriquer. Trés bien alors, et comment compte tu t'y prendre ? Tu va leur dire que la décomposition fonctionelle c'est pas bien ? Ou alors est-ce que tu va leur dire que c'est un plaisir imense de polluer l'espace globale avec des fonction qui n'ont de sens que dans un contexte trés locale ? A moins que tu ne leur fasse gouter au délice de surcharger le nombre d'arguments des fonctions plutôt que d'utiliser cette diablerie qu'est la fermeture ? Je serais curieux de savoir comment tu va faire avaler ça à tes élèves ... :-/ Mais si tu y arrive, ils/elles t'en voudront quand ils/elles auront appris à s'en servir par quelqu'un(e) d'autre.

Ah... une chose : la fonction imbriquée (et l'imbrication au sens général) est même un composant de l'essance fondamentale de JavaScript, y compris les fermetures -- closures (et alors aussi quand je vois que FireFox ne les implémente même pas efficacement, ça me fait doucement sourire .... )

Sinon, bien sûr Ok pour les prototype... j'en restais aux anciennes versions de JavaScript, c'est pour ça que je les excluait. Mais apparement il n'existe plus de navigateur qui ne les reconnaissent pas.... on s'y perd dans toutes ces différentes versions de JavaScript

Mais s'il te plait, oubli cette idée folle de déconseiller les fonctions imbriquées.

Pensée du jour: JavaScript is a better LISP

[Hibou57]

3) La moins facile à imaginer pour un développeur qui vient d'un language objet non-POOL (Prototyped Object Oriented Language ou Language Orienté Prototype d'object)

Ouf, ça y est, je viens de comprendre : tu aurais été plus clair si tu avais parlé d'héritage d'objet-à-objet. Je me suis renseigné, et en fait je viens de comprendre que le prototypage de JavaScript, beh, c'est du prototypage au sens pure du terme, même si la syntaxe biaise les choses et ne laisse pas apparaître leur vrai nature... faut dire qu'un langage qui s'appel «Java»Script et qui reprend la syntax du C........ pour finalement nous faire du pure prototypage à la Self/Simula ... pour une surprise, c'est une surprise.

Je crois que je vais reprendre tous mes codes et les reconcevoirs (mais dans l'ensemble, il resteront reconnaissable quand-même) avec ce nouveau regard.

Pensée du jour : JavaScript est né sous le signe de la confusion

Je marque le sujet comme résolu, et je fais mes sincères remerciements à gKsam qui a l'âme d'un(e) grand(e) developpeur(se) pour ses liens, ainsi qu'à FramyCompany pour avoir mis en avant l'aspect de l'unification objet-classe en JavaScript (même si tu ne l'a pas assez clairement exprimé à gout)

J'suis trop content de ce que j'ai appris cette nuit

[FremyCompany]

Si je dis que la dernière solution est à bannir, j'ai mes raisons

Je l'aime bien, contrairement à ce que tu dis, mais je l'évite le plus possible car c'est une mauvaise méthode...

Première chose à savoir, JavaScript est un langage interprétè, pas compilé

Code :

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

1
2
3
4
5
6
function cube(x) {
  function carre(x) {
    return x*x;
  }
  retur carre(x) * x
}

génère ce code-ci à l'interpretation (ce code est du pseudo-code, je ne garde que ce qui est utile à ma démonsration) :

Code :

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

1
2
3
4
5
6
window.setValue("cube", new JSFunc( args:=["x"], code:= {
  _currentClosure.setValue("carre", new JSFunc( args:=["x"], code:= {
    return x*x;
  });
  return _currentClosure.getValue("carre").apply(window, x) * x;
}):

Dit comme ca, ca ne veut rien dire mais en fait, à chaque appel de la fonction "cube", une nouvelle fonction "carre" est crée. Une fois l'appel de la fonction terminé, la fonction carre est supprimée de la mémoire. Ainsi, si tu appelle la fonction 1000 fois pendant que ta page est chargée, tu vas créer puis détruire 1000 fois la fonction carre.

Si elle était en dehors de la fonction cube, ce ne serait pas le cas.

Voila pourquoi il faut user de ca avec parcimonie. Bien utilisé il peut rendre un code plus propre sans trop de perte de vitesse, mal utilisé (dans une fonction très utilisée, ...) il peut diviser grandement les performances du site.
___________________________________________
Oui, tu as tout à fait raison, JavaScript est en fait très mal nommé, la faute à NetScape.

A l'origine, il s'appelait LiveScript. Puis NetScape a intégré dans sa version suivante Java(tm). Pour faire son coups du pub, il a renommé LiveScript en JavaScript. Ca donnait un truc genre "Avec Java et JavaScript, vos page n'ont jamais paru si dynamique avec NetScape"... Mais bon, faut avouer que maintenant ca porte à confusion inutilement...

[Hibou57]

Première chose à savoir, JavaScript est un langage interprétè, pas compilé

Oui, c'est un langage interprété, et tu fais bien de le souligner, puisque c'est justement une des raisons pour lesquelles l'imbrication lui convient parfaitement : pas seulement pour la modularité (c'est le seul mode d'accès à la modularité sous JavaScript), mais aussi pour les lambda expressions que représente la modularité. Et les lambda expressions sont justement typique des langages interprétés, et c'est leur plus grand avantage.

En d'autres mots : utiliser l'imbrication, c'est utiliser JavaScript pour ce qu'il a de meilleur. Et parce qu'il est interprété, il est conçus pour ça. Et de toute façon dans un langage ou la moindre affectation pèse nettement plus que dans un langage compilé, on en est plus à une imbrication prêt