Le Mercredi 18 Mai 2005 21:50, Charles-Henri d'Adhémar a écrit :
> Je suis entrain de me dire que le point soulevé par ton exemple
> peut-être résolu d'une autre manière sans avoir à faire des
> \............................................................. [ OK ]
> que je ne trouve pas super beau (mais j'ai rien de mieux ;-) )
>
> Typiquement :
> Quand on cherche un paquet dès qu'on en a trouvé au moins un alors on
> peut considéré le status de l'étape comme 'OK' et faire un print_status
> 'OK' dès qu'on trouve un paquet.
>
> Ce qui nous donnerai l'affichage suivant :
>
> Searching packages whose name contains "xine" ...
> Searching in "Nasgaïa CD" provider ...................... [OK]
> libxine1-1.0.1
> xine-ui-0.99.3
>
> Searching in "Nasgaïa contrib" provider ................. [FAILED]
>
> Car le print_status aura été fait avant les print_msg successifs
Comme je te l'ai dit hier soir sur IRC, le fait d'afficher l'état en remontant
à la ligne d'étape me paraît moins logique : ça interrompt le sens de lecture
traditionnel de bas en haut. Pour moi, afficher le titre de l'étape, puis ses
messages, puis son état me semble plus « normal ».
Mais la question que tu m'as posée sur IRC permet vraiment de savoir ce qu'il
faut afficher : « Qu'est-ce qu'on s'attend à obtenir lorsqu'on lance la
commande Ncooker search ? ». Pour ma part, je m'attends à ce qu'elle affiche
les paquets dont le nom contient « xine ». Si elle en trouve et qu'elle les
affiche, il n'est pas forcément nécessaire d'afficher l'état de la recherche.
Je me doute que la recherche est fructueuse rien que par le fait de voir les
résultats s'afficher à l'écran. Par contre, si la recherche ne donne rien,
j'aimerai avoir une indication. Ne serait-ce que pour être sûr que Ncooker a
bien compris ce que je lui demande et qu'il me dise qu'il n'a rien trouvé.
Donc voir [ FAILED ] s'afficher me permet d'avoir un retour. En fait, FAILED
n'est pas un état adapté pour cette commande, il vaudrait peut-être mieux
afficher [ NONE ].
Donc si Ncooker -v INFO search xine m'affiche :
Searching packages matching "xine"
Searching in "Nasgaïa CD" provider
libxine1-1.0.1
xine-ui-0.99.3
Searching in "Nasgaïa contrib" provider ................. [ NONE ]
ça pourrait éventuellement suffire pour savoir quels recherches sont
fructueuses et lesquelles ne le sont pas.
> Etant donné que le print_status décrémentera le level, il faut avoir une
> fonctionnalité du type INDENT ou NO_INDENT selon qu'on décide si par
> défaut c'est INDENT ou NO_INDENT. Je pencherai, comme toi, pour INDENT
> par défaut, et garder NO_INDENT : ça coute rien et ça peut être utile.
Je suis plus pour ne pas coder NO_INDENT et l'ajouter plus tard s'il y a un
réel besoin :-)
> De plus le coup du ALWAYS me convient parfaitement pour palier au
> problème associé que tu as très justement soulevé. Je pense même que par
> défaut un message de print_msg doit être ALWAYS affiché :-). On aurait
> donc NOALWAYS comme option (ou autre nom qui convient).
L'un ou l'autre, comme tu veux pour le moment :-) On verra à l'utilisation
lequel s'avère le plus pratique.
> - Cette solution suppose que le developpeur est discipliné et ne
> laissera pas de print_step ouvert avant de faire un print_msg.
> - Cette solution suppose qu'il n'y ait pas de cas où il faille faire un
> print_msg avant de faire un print_status : en vois-tu ?
>
> Tu en penses quoi ?
En fait, je me rends compte qu'il y a un truc qui me gène avec toutes ses
fonctions, ce sont leur nom :-) Je m'explique : pour moi, une fonction nommé
print_* s'utilise indépendemment d'autres fonctions de manière implicite.
Elle va afficher quelque chose, peut-être d'une manière particulière, mais
son but premier est avant tout d'afficher quelque chose. Un développeur
pourrait très bien se dire qu'il peut utiliser print_status() en plein milieu
de son code parce qu'il a simplement besoin d'afficher un état, sans jamais
utiliser print_step(). Or, print_status() est dépendante de print_step(),
mais rien n'indique cette dépendance, ce lien entre les deux fontions. Dans
le mécanisme qu'a proposé Julien, on voit qu'il y a un lien entre les deux.
Il l'a très bien illustré en faisant un parallèle avec les accolades
ouvrantes et fermantes. print_step() est en quelque sorte une accolade
ouvrante et print_status() une accolade fermante. L'une « ouvre » une entité,
et l'autre la « ferme ».
Est-ce que ce ne serait pas plus clair de renommer ces fonctions en
open_step() (ou begin_step(), start_step() (pas évident à prononcer :-) ) ?)
et close_step() (ou end_step() ?). Ainsi, on comprend qu'on ouvre/commence
une étape, et qu'à un moment il va falloir la fermer/terminer. Ce serait plus
parlant et les développeurs aurait moins tendance à utiliser un close_step()
en plein milieu de leur code, car le nom même de la fonction indique qu'il
faut faire une opération associée avant.
L'utilisation de open_step() ne changerait pas de print_step() : on ferait
« open_step <message> ».
Pour close_step(), par contre, l'état pourrait être optionnel : « close_step
[<status>] ». La raison en est que pour l'exemple de la commande Ncooker
search au-dessus, on a vu qu'il n'est éventuellemet pas nécessaire d'afficher
un état lorsqu'il y a des résultats. Mais indépendemment du fait d'afficher
un état ou non, close_step() diminuerait toujours l'indentation des messages.
On aurait donc les fonctions suivantes (sans tenir compte des
errors/warnings) :
open_step <step_title> : affiche le titre de l'étape avec l'indentation en
cours et augmente cette dernière.
close_step [<status>] : affiche l'éventuel état et diminue l'indentation
print_msg <message> : affiche le message avec l'indentation en cours.
À partir de là, il faut imaginer tous les cas d'utilisation possibles, sachant
que la seule contrainte logique est qu'un appel à open_step() doit se faire
avant un close_step().
Le cas particulier qui revient à nouveau est de savoir ce que doit faire la
fonction close_step() selon que le dernier message a été affiché par
open_step() ou print_msg() :-)
Lorsque le dernier message a été affiché par open_step(), on retombe sur le
comportement qu'on connait : close_step() affiche l'état au bout de la ligne
précédente.
Mais si le dernier message a été affiché par print_message(), que faire ?
Le cas simple, c'est :
open_step "Étape 1"
print_msg "un message"
close_step
Ici, close_step() n'a pas d'état à afficher. Elle se contente juste de
diminuer l'indentation. C'est ce qui serait utilisé pour mon exemple Ncooker
search plus haut.
Le cas compliqué, c'est :
open_step "Étape 1"
print_msg "un message"
close_step "OK"
A nouveau revient la question comment afficher l'état ? :-) Là, j'aurai
tendance à rester sur mon "\......... [ OK ]". Je sais que tu n'aimes par
trop, mais je ne vois pas comment présenter l'état autrement (idées
bienvenues :-) )
> Comme tu le dis c'est n'est que retarder le problème. Certes, je suis
> d'accord qu'on ne pourra pas mettre des garde-fous partout, mais je
> pense que ma crainte est fondée : pour l'instant on développe des
> commandes/modules relativement bas niveau. On arrive déjà à du niveau
> FULL. Imagines une commande haut niveau comme Ncooker update world. La
> tu peux être sur qu'on va sortir du terminal.
Oui, tu as raison.
> Ensuite le fait de diminuer le nombre des espaces pour l'indentation
> diminuera la clareté des messages comme tu le dis très bien.
>
> La solution :
>
> blablabla............
>
> > blebleble............
> > bliblibli............
> > blobloblo............
> > (+1) blublublu............
> > (+2) blyblybly............
>
> me plait le plus pour l'instant.
>
> Changes-tu ton opinion sur ce problème ou souhaites tu toujours le
> laisser de côté pour l'instant ?
Je sais pas. Ta solution de +1, +2, ... ne me convient pas tellement, mais je
n'ai pas mieux non plus (ça me rappelle -v 1, -v 2 ... :-) ). On peut le
laisser de coté pour l'instant et le traiter au moment où il apparaîtra
(peut-être plus tôt que je le pense :-) ), où jusqu'à ce qu'une idée
lumineuse surgisse :-)
++
Gontran
