27-08-2013, 09:33 AM
Pour le addToDOM, c'est à appendChild d'avoir géré le cas du noeud texte ou du noeud parent égal au noeud enfant (la doc manque de précision...); là, la doc dit "parent est un élément, enfant est un noeud" sans plus de précision...
Tester tous les cas dans le corps de la fonction est nécessaire si on veut qu'elle prenne tous les cas en compte (via des exceptions si on veut). Imagine qu'on applique le même procédé pour le matériel ou l'OS... Ce serait la misère O.o Si on se dit "bon allez, le disque dur je dis à l'OS qu'il fait 200Go donc l'OS ne va pas demander à écrire sur le 201eme giga"... Le jour où l'OS demande cela, le matériel crame... Le matériel doit forcément prendre ce cas en compte, à moins de prouver que le cas n'arrivera jamais.
C'est aussi issu du problème de l'absence de typage dans javascript.
Ok, l'approche "let it crash" peut marcher, mais je pense que le problem du "prove it" est l'absence d'outil automatisé. C'est comme se dire "les tests à la main, c'est nul ça bouffe du temps et faut recommencer à chaque fois", donc on est passé à des tests automatiques. A mon avis, le problème de "la preuve c'est nul ça bouffe du temps et c'est compliqué" répond au même besoin d'automatisation: si j'ai un analyseur de code (prouvé à la main :p) qui me permet de prouver que d'autres codes marchent, alors j'aurai des projets robustes, prouvés automatiquement (tiens, je vais m'essayer à ce genre de projet, cela me semble rentable à ce niveau là!).
(Roworll, si tu parles de tables type SQL, c'est déjà ce que le moteur de BDD fait: il lit toute la table, en optimisant avec un arbre si besoin, jusqu'à temps de trouver l'emplacement de la clef et si elle existe déjà, il remonte l'erreur. Faut pas considérer qu'une fonction "prouvée" doit absolument tout vérifier par elle-même: elle peut très bien s'appuyer sur d'autres fonctions prouvées).
Normalement, les bons langages ont justement des preuves formelles de fonctionnement, et je trouve cela dommage de "perdre" cette preuve entre le langage et le projet qui l'utilise.
Tester tous les cas dans le corps de la fonction est nécessaire si on veut qu'elle prenne tous les cas en compte (via des exceptions si on veut). Imagine qu'on applique le même procédé pour le matériel ou l'OS... Ce serait la misère O.o Si on se dit "bon allez, le disque dur je dis à l'OS qu'il fait 200Go donc l'OS ne va pas demander à écrire sur le 201eme giga"... Le jour où l'OS demande cela, le matériel crame... Le matériel doit forcément prendre ce cas en compte, à moins de prouver que le cas n'arrivera jamais.
C'est aussi issu du problème de l'absence de typage dans javascript.
Ok, l'approche "let it crash" peut marcher, mais je pense que le problem du "prove it" est l'absence d'outil automatisé. C'est comme se dire "les tests à la main, c'est nul ça bouffe du temps et faut recommencer à chaque fois", donc on est passé à des tests automatiques. A mon avis, le problème de "la preuve c'est nul ça bouffe du temps et c'est compliqué" répond au même besoin d'automatisation: si j'ai un analyseur de code (prouvé à la main :p) qui me permet de prouver que d'autres codes marchent, alors j'aurai des projets robustes, prouvés automatiquement (tiens, je vais m'essayer à ce genre de projet, cela me semble rentable à ce niveau là!).
(Roworll, si tu parles de tables type SQL, c'est déjà ce que le moteur de BDD fait: il lit toute la table, en optimisant avec un arbre si besoin, jusqu'à temps de trouver l'emplacement de la clef et si elle existe déjà, il remonte l'erreur. Faut pas considérer qu'une fonction "prouvée" doit absolument tout vérifier par elle-même: elle peut très bien s'appuyer sur d'autres fonctions prouvées).
Normalement, les bons langages ont justement des preuves formelles de fonctionnement, et je trouve cela dommage de "perdre" cette preuve entre le langage et le projet qui l'utilise.