Car quand on parse et qu'on tombe sur une variable, on ne rentre pas
dans cette variable. Elle sera traitée par la suite dans le parseAll.
Ainsi on ne peut pas connaître son unité si elle a une formule
A = B * C
B = D / E
C unité km
D unité €
E unité km
Quand on tombe sur B dans A, B n'est pas encore parsée, et donc on ne
peut pas savoir que B est en € / km.
Il faudrait parser B, ce qui serait trop couteux. On pourrait
implémenter un cache au parsing, implémenter les unités comme des fonctions, ou encore gérer les unités lors de l'éval (ce qui est bête, car on n'a pas besoin des valeurs pour inférer les unités)
Changements majeurs : espaces de noms, variantes imbriquées.
Des notes en .md expliquent les changements, ou les changements à venir
même si l'implémentation est en retard.
Un peu plus d'ordre dans le dossier /règles : les 'entités' et règles
calculatoires se rapprochent...
Leur base de calcul est l'assiette des cotisations sociales, qui inclut les indemnités.
Une variable d'objectif peut donc appeler le calcul d'une autre variable ayant une formule (plutôt que simplement des variables d'entrée).
[moteur] à refactorer.
On en profite pour que la simulation parte d'une variable unique, somme d'autres variables.
--> introduction du mécanisme 'somme'
Mael
Johan Girod
Laurent Bossavit