Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
"La première sécurité est la liberté"