[JS] Boucle for..in Array et ajout de methodes via prototype = conflit?!

[niahoo]

Obfuscation Oriented Programming en somme

[Xenos]

Oui, et c'est bien le but de la POO et de la programmation tut court. On crée des fonctions, des classes et des méthodes pour masquer le code qu'elles contiennent au regard du code qui les utilise.

[srm]

Non tu mélanges tout.

---

Que ça soit de la responsabilité de l'objet de savoir si c'est une victoire ou pas je suis d'accord et encore pas dans tous les cas. Mais que ce même objet sache ce qu'il doit faire en cas de victoire ça n'est généralement pas de sa responsabilité.

[Xenos]

J'vois pas en quoi c'est incompatible avec une méthode "forEachCallback()" ou "forEachDoThat()" (pour en revenir au problème initial)?

[srm]

C'est la même problématique, ça n'est pas toujours de la responsabilité de l'objet tout ce qui se passe dans l'itération.
J'ai poussé le principe au if pour voir jusqu'à ou allait ta réflexion de donner la responsabilité à l'objet.
Et je vois qu'en gros tu as aucune limite, tu veux tout lui donner.

[Xenos]

Il y a des règles précises concernant ce qu'un objet doit prendre en charge? Il me semble que si mon objet possède une tableau de données en guise de paramètres, si j'ai un traitement à faire sur chaque donnée, c'est de la responsabilité de l'objet de faire au moins l'itération, et non de la responsabilité de l'utilisateur de la classe d'itérer sur la collection pour exécuter une fonction / méthode.

[niahoo]

Bof, c'est pratique de pouvoir itérer sur une collection de l'extérieur. Par exemple dans Backbone c'est cool de pouvoir faire un map sur tous les modèles d'une collection pour récupérer des infos ou les lier à un autre objet.

[Xenos]

On va alors dire que ça dépend des préférences de chacun, donc j'vais ni dire que j'ai raison, ni dire que j'ai tort
Mais je soulèverai quand même le fait que le "forEachCallback" (ou le "for (var i...)") en met plein les dents au Array.forEach(func) :p

(Ca me parait juste pas pratique d'utiliser un système type "si je veux enlever les livres d'une bibliothèque, je demande à un opérateur de le faire", je préfère passer pour un fou et dire à ma bibliothèque "vide-toi!" plutôt que de devoir manipuler deux objets: l'opérateur qui doit faire le vide et la bibliothèque à vider)

---

Après re-test, je pondérerai un peu plus mon propos en spécifiant que Firebug ralenti énormément le foreach, mais il ne ralentit par le for (var i), d'où l'énorme écart (x600) que l'on avait précédemment.

Firebug coupé, l'écart se réduit à du x8 (6ms pour for var i contre 48ms pour foreach, avec un tableau de 5.000.000 d'éléments.
J'ajouterai que les deux sont au même niveau quand le tableau contient des objets, et que Array.forEach travaille par valeurs dans le cas des types de base.

[srm]

Je veux tous les livres puis je les présente à l'utilisateur qui peut les modifier et je les enregistre de nouveau.
Ce n'est pas du tout là la bibliothèque de faire tout ça.

[Xenos]

Sauf qu'on peut considérer que c'est à la bibliothèque de communiquer le message de modification à chacun de ses livres.
Ce qui me gène dans l'idée du "je demande à la bibliothèque tous ses livres et je les modifie", c'est qu'en un sens, on en sait beaucoup trop sur la bibliothèque. Comment pourrait-on alors passer d'une bibliothèque papier à une bibliothèque numérique avec ce système? Ou à une autre forme de bibliothèque encore totalement inconnue de nos jours? Le principe de "faire sortir le livre" de la bibliothèque fait filtrer trop d'informations vers l'extérieur pour être facilement maintenable.

Un exemple peut être plus compréhensible: si ma bibliothèque contient des nombres en Java. Alors, cette bibliothèque va contenir, par exemple, des objets "Integer". Sauf que plus tard, j'ai besoin d'un super grande bibliothèque, et je dois donc passer à des entiers simples (pas des objets). Donc il faut que la méthode qui renvoie les "livres" (objet Integer) de ma bibliothèque soit adaptée, et finalement, l'utilisateur ne modifie plus le livre de la bibliothèque, puisqu'il modifie l'objet Integer que la bibliothèque a du générer pour rester compatible... Ce genre de "fuite" d'information d'une classe génère donc un fort couplage, et rend la maintenance hyper lourde (mais c'est une question de goût peut-être).
Le coté "boîte noire" n'est pas assez présent pour moi si on peut demander à cette boite noire (bibliothèque) de nous renvoyer sa liste de composants (livres).