Le Mercredi 11 Mai 2005 19:46, Julien L. a écrit :
> Salut tout le monde,
Salut :-)
> - actuellement, le développeur doit fixer le niveau de détail du message
> qu'il veut afficher. Comme vous l'avez fait remarquer, tout cea est assez
> subjectif et pose un certain nombre de problèmes. J'ai l'impression que
> votre solution consiste à "déplacer" le niveau de détail fixé par le
> développeur pour qu'elle suive la logique de l'exécution (appel d'une
> commande à partir d'un module, ...). Le développeur se casse donc la tête à
> fixe un niveau de détail pour le voir ensuite modifier. A vrai dire, cela me
> paraît "bizarre" comme fonctionnement.
Oui, c'est vrai que si le développeur utilise print_msg "INFO" "quelque chose"
dans le code de son module, il peut logiquement s'attendre à voir s'afficher
"quelque chose" quand il fera « Ncooker -v INFO
<une_commande_qui_utilise_son_module>", mais ce ne sera pas forcément le cas,
ce qui peut effectivement être déroutant ! :-) . Je pense que tu as raison,
il faut dissocier les noms utilisés par l'utilisateur pour sélectionner un
niveau de verbosité des noms utilisés par le développeur pour afficher ses
messages à différent niveau.
> Partant de ces remarques, mon idée est la suivante.
>
> La fonction print_msg ne prend plus qu'un seul argument : le message. Le
> niveau de détail, trop subjectif et surtout trop relatif aux autres
> messages, sera calculé par le gestionnaire de messages. Ainsi, le
> gestionnaire de messages conserve le niveau de détail (et donc le niveau
> d'indentation) en variable globale.
>
> Lorsque print_msg est appelé, le message passé en argument est affiché
> (avec la bonne indentation) et le niveau courant est incrémenté.
>
> Lorsque print_status est appelé, le résultat passé en argument est affiché
> et le niveau courant est décrémenté.
>
> C'est un peu comme le système de parenthèses. Une fonction ouvre la
> parenthèse. Si cette même fonction est appelée, une sous-parenthèse est
> ouverte. Lorsque l'autre fonction est appelée, la dernière parenthèse
> ouverte est fermée.
Je trouve ton idée vraiment très intéressante, et elle me séduit
beaucoup ! :-)
Elle simplifie grandement la vie du développeur et reporte toute la complexité
dans la librairie de gestion des messages. De plus, comme aucun niveau de
message n'est précisé lors des appels à print_msg(), il devient possible
d'ajouter ou supprimer des niveaux de verbosité si nécessaire sans avoir à
remodifier tous les modules : tout se fait dans la lib :-)
Pour préciser un peu les choses, print_msg et print_status pourraient utiliser
deux variables : l'une pour augmenter/diminuer l'indentation des messages,
l'autre pour indiquer si le statut du dernier message affiché a été indiqué.
En pseudo-code, ça donnerait :
indentation=0
print_msg () {
Si niveau de verbosité sélectionné par l'utilisateur == FULL
ou Si indentation <= niveau de verbosité sélectionné par l'utilisateur
afficher le message
statut_affiché = non
Fin Si
indentation = indentation + 1
}
print_status () {
Si niveau de verbosité sélectionné par l'utilisateur == FULL
ou Si indentation <= niveau de verbosité sélectionné par l'utilisateur
Si statut_affiché == non
afficher le statut
statut_affiché = oui
Fin Si
Fin Si
indentation = indentation - 1
}
Exemple d'utilisation :
1 print_msg "niveau 1 message 1 ..."
2 print_msg "niveau 2 message 1 ..."
3 print_status OK
4 print_msg "niveau 2 message 2 ..."
5 print_status OK
6 print_status OK
7 print_msg "niveau 1 message 1 ..."
8 print_status OK
Ce qui donnerait :
$ Ncooker -v MAIN <command>
niveau 1 message 1 ... [ OK ]
niveau 1 message 2 ... [ OK ]
Ici, c'est le print_status() de la ligne 6 qui affiche le OK du premier
message.
$ Ncooker -v INFO <command>
niveau 1 message 1 ...
niveau 2 message 1 ... [ OK ]
niveau 2 message 2 ... [ OK ]
niveau 1 message 2 ... [ OK ]
Ici, le print_status() de la ligne 6 n'affiche rien car la variable
statut_affiché a déjà été positionné à "oui" lors de l'appel précédent ligne
5.
Le seul point noir que je vois dans tout ça, et que si on prend un appel à
print_status au hasard dans le code, on ne sait absolument pas à quel niveau
de message il se rapporte. Il faut remonter le code pour repérer tous les
appels à print_msg, et leur print_status associé, pour trouver l'appel au
print_msg qui correspond. Pour déboguer, ça va être sympa ! :-D Mais bon,
avec de « bons » commentaires, ça peut le faire :-)
Sinon, je pense que tu as également raison sur le fait d'utiliser une autre
fonction pour les messages d'erreur. La fonction print_msg actuelle possède
deux comportements différents selon que le niveau du message à afficher soit
ERROR ou WARN d'un coté, et INFO, DETAIL ou FULL de l'autre. Comme tu l'as
dit, cette fonction garderait bien 2 paramètres : le type d'erreur et le
message d'erreur.
++
Gontran
