# HG changeset patch
# User Olivier Delalleau <delallea@iro>
# Date 1284558131 14400
# Node ID 1a1c0c3adccaeaa9ae6f56b68c19f197f3497faf
# Parent  be53f56b37b82ba3ba57291cbf538ffae266d69c
coding_style: Added suggestion made by email by Francois about type checking

diff -r be53f56b37b8 -r 1a1c0c3adcca doc/v2_planning/coding_style.txt
--- a/doc/v2_planning/coding_style.txt	Tue Sep 14 23:24:59 2010 -0400
+++ b/doc/v2_planning/coding_style.txt	Wed Sep 15 09:42:11 2010 -0400
@@ -350,4 +350,32 @@
     OD: Check Django's guidelines (link above)
    * Standardize the merge commit text (what is the message from fetch?)
 
+Type checking
+-------------
 
+(Suggested by Francois Savard)
+
+vu que vous êtes en train de vous occuper de l'aspect coding style, je
+mentionne ceci, à faire ce que vous en voulez: j'aime bien éviter des
+erreurs sur l'ordre de mes paramètres, sur les assumptions sur les
+paramètres etc. en faisant des argument check. Ça remplace un peu le
+static type checking des langages genre Java.
+
+En Python y'a une façon élégante de définir ses propres typecheckers,
+value checkers etc. et ensuite les passer en paramètre à un décorateur de
+fonction:
+
+http://code.activestate.com/recipes/454322-type-checking-decorator/
+
+(Juste un exemple, vu que les checks peuvent être plus élaborés, inclure
+des value checks (>0 etc.), être flexibles pour ne pas demander que ce
+soit un type fixe mais plutôt que ça réponde à certaines contraintes (que
+ça "ressemble" à un float, p. ex.). J'avais développé une lib pour faire
+qqch du genre en Javascript).
+
+Je ne sais pas si vous comptiez parler de ça, et si ça vaut la peine, mais
+personnellement je préfère du code à des commentaires qui peuvent être out
+of sync avec le contenu d'une méthode. Si vous croyez que ça vaut la peine,
+vous pourriez p-e définir des type/value-checkers standards pour éviter que
+tout le monde redéfinissent les siens à sa façon.
+