Salut tout le monde,
Salut Chicha,
Ce qui est important pour un développeur c'est pas tant de définir le
niveau
entre les modules/commandes que de le définir au sein d'une même
commande/module.
C'est vraiment ça qui est important. Le but est de respecter la hierarchie
des
messages au sein d'un même module/commande, ceci relativement au context
dans
lequel il est utilisé. c'est au développeur de le définir la hiearchie au
sein
d'une commande/module.
Après c'est à print_msg et au module/commande père/mère de décider si les
messages des modules/commandes filles doivent être considéré comme un
niveau
inférieur ou égale à ses propres messages.
Je comprend ce que tu veux dire mais, avec ce système, le développeur
qualifie un message de niveau INFO et, au final, son message est affiché au
niveau DETAIL. Je trouve que c'est un peu déroutant.
Non, ce n'est pas toujours le cas. un print_msg n'est pas forcément
suivit d'un
print_status.
Exemple :
print_msg WARNING "Some nbuilds are not up to date. You should run Ncooker
update to have the latest version" (message fictif)
Donneras l'affichage suivant :
Some nbuilds are not up to date. You should run Ncooker update to have the
latest version
print_msg INFO "Downloading foobar..."
Donneras l'affichage suivant :
Downloading foobar...
Ensuite dans le code si tu fais:
print_status INFO OK
alors le message précédent sera transformé et deviendra :
Downloading foobar......................... [OK]
Ce que fait print_status c'est juste ajouter des .... et mettre le statut à
la
fin d'une ligne.
Si un développeur fait par erreur :
print_message ERROR "Your nbuild is corrupted"
[plusieurs lignes de code]
print_status OK
Alors l'affichage final sera :
Your nbuild is corrupted.................. [OK]
Ce qui n'est pas du tout l'effet voulu
D'accord.
Inversement, si tu écris :
print_message INFO "Downloading source archive"
[plusieurs lignes de code]
print_status FAILED
L'affichage final sera :
Downloading source archive.................. [FAILED]
Tu as donc utilisé un niveau INFO pour afficher... une erreur.
En fait, je pense qu'il faut distinguer les messages d'"étape" (qui
indiquent l'avancement du traitement) et les erreurs/warning (qui peuvent
être aussi bien affichés en milieu de traitement qu'en bilan de traitement).
Je complète ce que j'ai dit plus haut : le niveau de détail n'est pas (ou
peu)
subjectif. Un développeur peut résonnablement définir au sein d'une même
commande ce qui est de l'info, du détail et du super détail. Par contre il
ne
peut pas prévoir à l'avance si la commande qu'il code sera utilisée au
premier
niveau ou dans un niveau de détail.
C'est cela même pourquoi je propose que le développeur ne précise plus de
niveau de détail et que le gestionnaire de messages détermine entièrement
par lui-même le niveau du message.
Avec ton idée on perd toute notion d'ERROR et WARNING qui sont au
dessus de tout
cela.
print_msg "Fatal error : your nbuild is hightly corrupted, it may damage
your
computer" doit être affiché tout le temps (sauf si verbosity = NONE) que ça
intervienne au niveau 0 ou au niveau N+100. Avec ton système on perd le
message
si l'utilisateur fait -v INFO
Si c'est une erreur, elle doit être affichée sur la sortie d'erreur et pas
sur la sortie standard. Une fois encore, cela montre qu'il faut bien faire
la distinction entre les étapes et les erreurs/warning.
Je pense qu'il peut être envisagable d'avoir une fonction print_error avec
deux arguments :
- le niveau de l'erreur (WARNING, ERROR, FATAL)
- le message d'erreur
Cette fonction ne modifierait pas le niveau de détail courant du
gestionnaire. Elle se contenterai d'afficher le message (avec ou sans
indentation).
Je pense sincèrement que ce n'est pas la meilleure solution.
Je ne sais pas si elle est naïve, mais je ne vais sûremment pas la jeter à
la
poubelle, le débat avance et c'est l'essentiel :-)
Une fois de plus, je n'ai pas la prétention d'avoir la meilleure solution.
Je pense qu'il faut essayer de faciliter la vie du développeur tout en
offrant de jolis messages à l'utilisateur. A vrai dire, les fonctions que
vous proposez (shiftMessageLevel et unshiftMessageLevel) me font un peu peur
car je trouve qu'elles complexifient le travail du développeur.
++
Chicha
A+
--
Julien
_________________________________________________________________
Ne cherchez plus, trouvez ! Avec le nouveau MSN Search.
http://search.msn.fr/
