+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [JS] Boucle for..in Array et ajout de methodes via prototype = conflit?! (/showthread.php?tid=7068)
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Argorate - 29-07-2013
moi je veux bien voir les benchmarks^^
Je connaissais pas cette fonction.
Sinon le rendre non énumérable marche bien oui, merci.
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Maks - 29-07-2013
Citation :Rien de plus simple alors que d'avoir du forEach, du isEmpty, ou autres méthodes persos, attachées à cette classe. Non?
forEach() c'est pas une méthode perso...
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Xenos - 29-07-2013
Oui, mais l'idée est de ne pas passer par un callback, et de remplacer le [].forEach(callback) par une méthode type Object.forEachCallback(), qui pourra utiliser for & length, et donc, faire péter les compteurs du benchmark, tout en restant OO :p
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - niahoo - 29-07-2013
tu veux faire péter les benchmark en réimplémentant une méthode native par une méthode en javascript ?
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Xenos - 29-07-2013
Sous la forme
Code :
function forEachCallback()
{
for (var i=0, s=this.datas.length; i<s; ++i)
{
// code du callback
}
}Au lieu de
Code :
var func = function ()
{
// code du callback
}
myObject.datas.forEach(func);Fichier-test:
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<script>
function test()
{
var datas = [];
for (var i = 0;i<100000;++i)
datas.push(0);
function forEachCallback()
{
var debut = (new Date()).getTime();
for (var i=0, s=datas.length; i<s; ++i)
{
var that = datas[i];
}
var fin = (new Date()).getTime();
console.log('forEachCallback: ', fin-debut);
}
forEachCallback();
var func = function ()
{
}
var debut = (new Date()).getTime();
datas.forEach(func);
var fin = (new Date()).getTime();
console.log('forEach: ', fin-debut);
}
</script>
</head>
<body onload="test()">
</body>
</html>Résultat:
1 ms pour le foreachCallback
600ms pour le .forEach() natif
Donc, oui, ici, on ne fait pas une bête réimplémentation de ce qui existe déjà nativement, mais bien une optimisation (sauf si je me suis viandé dans le code, mais cette fois, je crois que je n'ai aps oublié de réinitialiser le compteur de temps, et oui, l'init est moche, mais j'ai pas trouvé mieux)
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - niahoo - 30-07-2013
tu te rends bien compte que tu ne passes pas de callback dans ton forEachCallback ? Ou alors j'ai pas compris le but de foreach callback ...
En fait j'ai testé, ta fonction avance pas mal au final (bien que je n'ai toujours pas compris ce qu'elle apportait de mieux que Array.foreach ...)
Par contre elle n'apporte pas la possibilité de spécifier un contexte ni de zapper les cases vides du tableau. Donc effectivement ton benchmark va donner ta fonction comme plus rapide. D'autant plus que tu ne lui envoies pas de callback comme je l'ai dit, donc en l'occurence ta fonction ne fait ... rien.
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Xenos - 30-07-2013
Oui, il n'y a pas de callback dans forEachCallback, c'est justement le principe de la méthode. Le "callback" n'est pas passé à la fonction: il est dans la fonction même, d'où le fait d'avoir nommé la fonction avec le terme "Callback".
Le callback pèse lourd dans le benchmark, et ce n'est pas forcément la manière la plus élégante de faire les choses, car faire un "Object.datas.forEach(Object.treatment)" n'est franchement pas beau (je trouve), alors qu'un "Object.forEachDoTreatment()" est plus élégant.
forEach(func) ne fait rien non plus si on ne met rien dans "func". Spécifier les contextes, c'est cool, mais ce n'est pas très OO, or, Array.forEach est plutôt OO, donc je trouve l'idée de "forcer" un contexte plutôt mal venue.
Elle permet de zapper les cases vides du tableau si on le lui dit dans le contenu de la boucle.
Ce que j'essaie de mettre en avant, c'est que vouloir faire un "forEach" méga général sur tous les tableaux n'est ni le plus pratique, ni le plus performants. Il faut mieux faire une méthode forEachDoThat(), forEachDoThis()... pour les classes qui ont besoin de faire un traitement sur leurs tableaux de données.
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Argorate - 30-07-2013
je vois l'idée, mais réinventé la boucle à chaque fois, c'est un peu lourd point de vu du codeur et duplication de code (qui génère la boucle, puisque le traitement change lui).
je vais faire des tests avec le length et le for..in pour voir, peut etre que le plus simple est simplement de n'utiliser que le meilleur des deux...
Re: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - srm - 31-07-2013
Je ne trouve vraiment pas ça approprié, ça me donne la même impression que si tu voulais faire ifVictory au lieu de if (victory)
RE: [JS]Boucle for..in Array et ajout de methodes via prototype = conflit?! - Xenos - 31-07-2013
Oui, je fais du "ifVictory", mais plutôt au sens "object.doVictory", et dans le doVictory, on a le test de victoire (et donc le contenu de la méthode se déroule que si la condition de victoire définie dans cette même méthode est remplie).
Cela pousse l'OO jusqu'au bout: au lieu de faire une condition "ailleurs" et de faire exécuter le code correspondant là aussi "ailleurs", je fais les deux dans la classe concernée par la victoire (ou par le parcours des données). Cela respecte d'ailleurs bien plus les design patterns et l'encapsulation:
Code :
if (object.isVictorious())
object.victory();Le couplage est très fort entre la fonction où se trouvent ces lignes et la classe de "object".
Code :
object.doVictoryIfNeeded();Le couplage est bien plus faible (le code en "sait" moins sur la classe de "object" que le précédent code).