<div dir="ltr"><div><div><div><div><div>Bonjour Gautier,<br></div>Je ne vois pas trop la partie TDD, je trouve personnellement les tests peu expressifs. IMHO illustrer le TDD en Haskell implique de partir de Quickcheck. Tes tests sur l'égalité et les propriétés des Temperatures pourraient tirer parti de cet outil par exemple. Par ailleurs si tu veux utiliser HSpec alors je te suggérerai de "suivre le grain" de l'API. <br>
<br><div class="" id="LC19"><span class="">describe</span> <span class="">"Both Fahrenheit"</span> <span class="">$</span> <span class="">do</span></div><div class="" id="LC20"> <span class="">it</span> <span class="">"same"</span> <span class="">$</span> <span class="">do<br>
<br></span></div><div class="" id="LC20"><span class="">c'est pas trés "beau", il serait plus logique d'avoir quelque chose du genre:<br><br></span><div class="" id="LC19"><span class="">describe</span> <span class="">"Both Fahrenheit"</span> <span class="">$</span> <span class="">do</span></div>
<div class="" id="LC20"> <span class="">it</span> <span class="">"should be equal given same value"</span> <span class="">$</span> <span class="">do</span><div class="" id="LC20"> <span class="">it</span> <span class="">"should be different given different values"</span> <span class="">$</span> <span class="">do</span></div>
</div></div><br></div>Mais encore une fois, l'exemple choisi se prêterait pas mal à l'utilisation de quickcheck.<br><br></div>Dans le code principal, je ne vois pas trop le problème que tu as avec ta classe: j'arrive à compiler ce code sans problème en rajoutant les flags qui vont bien (ghc me le dit...). <br>
<br></div>Je ne suis pas sûr non plus que l'utilisation intensive d'une notation "point-free" aide à la compréhension.... Surtout avec un pipeline de 10 fonctions. Je te suggérerai de détailler chaque partie de la fonction. <br>
<br>Une approche que j'aime bien utiliser et qui fonctionne bien en Haskell c'est de partir de la fonction principale qui ne fait rien, puis de la décomposer. <br><br><br></div>Cordialement,<br></div><div class="gmail_extra">
<br clear="all"><div><div dir="ltr"><div><div><div>--<br></div>Arnaud Bailly<br></div>FoldLabs Associate: <a href="http://foldlabs.com" target="_blank">http://foldlabs.com</a><br></div></div></div>
<br><br><div class="gmail_quote">2014-04-03 16:10 GMT+02:00 Gautier DI FOLCO <span dir="ltr"><<a href="mailto:gautier.difolco@gmail.com" target="_blank">gautier.difolco@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 3 avril 2014 11:00, Gautier DI FOLCO <span dir="ltr"><<a href="mailto:gautier.difolco@gmail.com" target="_blank">gautier.difolco@gmail.com</a>></span> a écrit :<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 3 avril 2014 10:44, Sylvain Henry <span dir="ltr"><<a href="mailto:hsyl20@gmail.com" target="_blank">hsyl20@gmail.com</a>></span> a écrit :<div>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Pour l'immutabilité, je montrerais les Lenses.<br></div></blockquote><div><br></div></div><div>Bonne idée<br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Eviter d'utiliser des listes partout, notamment dans DayStmt, WeekStmt et MonthStmt, vu que le nombre de champs est fixe. </div></blockquote><div><br></div></div><div>Pas forcément, tu ne peux avoir que les relevés de 40 jours par exemple, ce qui fais que tu as un mois et une semaine incomplète.<br>
</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Utiliser des lenses ici serait pas mal, surtout pour réécrire la fonction finale. Si je comprends bien elle fait une sélection et une réduction, donc parfait avec des lenses.<br>
</div></blockquote><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
Je ne suis pas convaincu par le Monoid, une simple fonction de réduction suffirait : <br>toStats :: [Temperature] -> Statistics<br>Là c'est compliqué inutilement je trouve.<br></div></blockquote><div><br></div></div>
<div>
Du coup tu perds la notion de groupes de relevés (jour, semaines, mois) et tu te retrouve à gérer le "conflit" °C/°F en même temps que le calcul des stats. <br></div></div></div></div>
</blockquote></div></div></div><br></div><div class="gmail_extra">si je donne l'impression de vous rembarrer pour le plaisir, il n'en est rien, je tente juste d'exposer mes choix et de comprendre ce qui ne va pas (et j'ai l'impression de mal m'exprimer).<br>
</div><div class="gmail_extra">Le but c'est de montrer le TDD, il y a un aspect incrémental à mettre en valeur et arriver à quelque chose de complexe en partant de choses simple à mettre en valeur.<br></div><div class="gmail_extra">
Le coding dojo en lui même n'est pas spécifiquement fonctionnel (je pense qu'on sera 3/20 à coder dans un langage fonctionnel, au sens large), mon but est de dire : la POO ne résout pas tout proprement, regardez en FP.<br>
</div><div class="gmail_extra">Je pense mes intentions sont plus claires.<br></div></div>
<br>_______________________________________________<br>
Haskell-fr mailing list<br>
<a href="mailto:Haskell-fr@haskell.org">Haskell-fr@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-fr" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-fr</a><br>
<br></blockquote></div><br></div>