Salut Gontran, Salut tout le monde :-) J'aivais poste ce mail AVANT notre conversation sur l'IRC. Tu l'as lu APRES notre conversation :-)
Dans tous les cas c'est pas grave car tu fais bien avancer les choses, cf plus loin.... Quoting Gontran <[EMAIL PROTECTED]>: > > 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 ». Je suis d'accord, ca se tient tres bien :-) > > 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. Ca me va parfaitement :-) > Je suis plus pour ne pas coder NO_INDENT et l'ajouter plus tard s'il y a un > réel besoin :-) Ok pour moi :-) >> 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. Je vais donc garder ALWAYS par defaut car je ne vois pas de cas avec un message qu'il ne faille pas afficher. Tu en vois ? De plus je prefererais utilise VEBOSE a la place d'ALWAYS. print_msg VERBOSE "blablabla...." C'est plus claire, et on sait qu'il sera affiche selon la verbosite. si rien n'est specifie alors le message est toujours affiche. Ca te va ? > > 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 :-) ) Ta solution open_step / close_step me convient parfaitement. Je la trouve meme tres bonne. La nuit a portee conseil je vois... :-) Moi ce qui me gene c'est d'avoir une fonction qui s'appelle print_msg. On ne voit pas clairement dans quel cas l'utiliser. Ensuite pour l'instant on va coder une fonction print_msg qui va avoir un comportement particulier : le message sera indente correctement, la verbosite globale ne sera pas modifiee. Le message sera affiche sauf si on utilise l'option NOALWAYS (ou VERBOSE si on choisit de l'appeler VERBOSE). Maintenant qui sait ce que nous reservera l'avenir ? Peut-etre que demain on aura besoin d'une fonction qui fasse a peut pret la meme chose, mais pas tout a fait. Et on sera emmerde car on voudra aussi l'appeler print_msg. Pour l'instant on voit l'utilite d'afficher des messages pour donner un resultat d'une commande qui en necessitent un : Ncooker search (Ncooker config --show si on decide de le faire). Mais on a pas trop d'autres exemples pour l'instant. Je te propose print_result ( ou autre nom qui te parle plus ) print_result s'indente de 1 par rapport a la step appelante. close_step doit toujours etre appellee apres une serie de print_result, mais le statut sera ignore car un print_result est un statut OK ou SUCCEDED implicite. Avec ca on couvre tous nos besoins actuels et on laisse la porte ouverte a d'autre fonctions print_*. ca te va ? >> 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 :-) Ok pour moi : on le laisse de cote jusqu'a ce que le probleme apparaisse ou qu'un de nos lecteurs (s'il en reste pour ce probleme ;-) ) nous apporte une solution sympa :-) ----- Fin du message transféré -----
