dans le cas de ton lecteur mp3, comment tu indiques (...) merci pour l'info.
Tu n'as pas l'impression que tu rales parce qu'un logiciel ne répond pas a ton besoin ? Tout ce passage c'est : comment je fais ci ou ça avec ? La réponse est : tu ne le fais pas vu que ce n'est pas fait pour ça.
Tu aurais une lib de gravure avec juste gboolean burn(char* isoname) ça serait le même problème. Ta critique porte sur les fonctionnalités de cdrecord, non pas sur les techniques utilisées par son interface pour communiquer avec.
(..)C'est juste une question de bonne pratique(...)
Oui, dans le but de maintenir le machin et d'en faire quelque chose d'évolutif. Parfois, on fait un truc tout con qui répond juste a un besoin et alors, la bonne pratique est de faire simple. Ensuite, la séparation peut tres bien etre faite, au moins au niveau source. C'est juste que tu n'as pas envie de te taper les contrôles inhérents à la création d'une lib parec que tu ne programme que pour une ligne de commande.
ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général (...)à parser par une application tierce-partie
Il ne t'est jamais venu a l'idée que ce n'etait pas fait pour ? Encore une fois, tu rales parce que tu essayes d'utiliser un outil dans un contexte pour lequel il n'a pas été fait (typiquement, le fait de parser des fichiers config automatiquement alors qu'ils ne sont pas faits pour ça).
Les config XML c'est l'inverse. Avec VI, le XML c'est infect et illisible. Normal ce n'est pas fait pour ça.
Dans un cas c'est documenté, pas dans l'autre.
Si le gars ne documente pas, commande ou lib, tu es dans les deux cas dans la mouise. C'est un probleme de doc, pas de techno.
C'est pas un peu très idiot ?
Pas plus que de transformer un appel interne du front end en un appel à une lib. LA lib traitera aussi les parametres pour s'assurer qu'ils sont valables et accesoirement, les transformera peut-être pour ses besoins internes.
Le principe est le même : c'est une transformation des parametres transmis au frontend pour l'envoyer vers le truc qui va éventuellement les transformer afin d'éxecuter sa tache avec les bons paramètres.
Il n'y a que le chemin technique qui differe. Dans certains cas, c'est plus facile par du code, dans d'autres c'est plus facile via une ligne de commande.
Juste pour la précision (...) je ne vois pas en quoi celà va dans ton sens
Je n'ai cité ça que pour illustrer le fait que, comme mes autres exemples, quand les methodes lègeres sont sorties du panier, elles etaient souvent présentées comme LA solution à tous les problèmes. Comme toujours, on en est revenu et on les considère maintenant que comme un des outils pour gérer un projet, au même titre que les autres méthodes. On choisi de les utiliser ou pas en fonction du contexte du projet, pas uniquement parce que çai mieux (tm).
La ligne de commande comme IPC, n'est pas plus que la librairie, l'interface ultime, même si d'après toi elle a été présentée comme tel. En tous cas, je n'ai jamais affirmé que c'était LA solution, je dis juste qu'il est crétin de la bannir sous prétexte que çai mal (tm).
Oui effectivement, seulement si il a les sources.
Oui evidemment :) De toutes façons, si tu n'as pas les sources, lib ou commande, tu feras très probablement des trucs porky si tu veux étendre les fonctionnalités de l'outil, parce que tu ne pourras faire les ajustements nécessaires dans l'outil pour qu'il prenne en charge tes nouvelles utilisations.
Celà peut être légitime(...)communication privilégié
1- je ne vois pas en quoi les chaines de caractères sont des formats à la con : c'est humainement compréhensible (contrairement à un hash, ou une structure/record ou autre type composite) et ça se génère et gère tres bien dans bon nombre de langage (je ne connais que le C qui rend leur gestion plus délicate).
2- un programme est fait pour être utilisé dans un but et dans un contexte. Il est évident que si ton programme n'est fait QUE pour des machines, il existe d'autres moyens que la ligne de commande et probablement plus adaptés. Maintenant, si tu veux quelque chose d'utilisable par des humains (une commande) et parfois, par des machines, la ligne de commande c'est une possibilité qui peut s'avérer plus interessante que les autres, particulierement dans le cas que j'ai cité : paramétrage d'un processus long et non interactif.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant.
Non, ça joue le morceau que je demande, ça l'arrete quand je n'en veut plus ou quand il est terminé, le tout en mode graphique : ça fait ce pour quoi c'est fait.
il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité.
Dans ce cas, on devrait utiliser une librairie :) Ce n'est pas très malin de passer par la ligne de commande si on veut de l'interactivité durant le traitement. Il me semble que je l'ai déjà dit avant.
Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure...
Non, mon besoin c'est : je selectionne tous les paramêtres de la gravure graphiquement, je clique sur GO et quand c'est fini le frontend me dit "ça marche / ça marche pas" en fonction du résultat : la ligne de commande c'est nickel pour ça.
Si tu as les besoins que tu cites, alors oui, utilises une lib.
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire
Beh si. Il te faut coder ta lib béton parce que l'utilisateur de la lib peut t'envoyer du yahourt. Si je fais un burn(NULL), et que tu ne testes pas dans burn() tes paramètres d'entrée, alors segfault. Si j'ai une fonction burn() identique dans un programme et pas en lib, je n'ai pas besoin de faire ce test, parce que je sais que je n'y enverrais jamais NULL si je sais que j'ai fait le controle en amont.
Evidemment, ce n'est qu'un exemple, mais ce n'est evidemment pas le seul et puisque tu demande un truc indépendant du langage (d'ailleurs, le débordement de buffer ce n'est pas spécifique au C), en voila un autre :
Toujours en restant sur l'exemple de la gravure, tu dois vérifier dans burn() que le device cible existe bien, ou au moins gérer l'erreur si l'utilisateur de la lib envoie n'importe quoi. Si c'est une fonction intégrée un programme complet, ce n'est pas forcément nécessaire si tu as fait le controle en amont (si l'utilisateur n'a qu'un choix limité, par exemple).
De toutes manières c'est hors sujet.
D'ailleurs, il me semble bon de rappeller, au milieu de ce troll, que le sujet n'est pas "la librairie c'est mieux". Le sujet est "c'est abérrant d'utiliser des redirections d'I/O dans des programmes". Mon propos est : "parfois les redirections d'I/O c'est plus adapté qu'une API" et le tien, si je l'ai bien compris est : "dans tous les cas, il devrait y avoir une API et on ne devrait jamais utiliser la redirection I/O comme ipc".
plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Ce ne sont pas que des habitudes : les mecs qui utilisaient ça plutot qu'autre chose le faisaient de manière aussi réfléchie que maintenant. Certaines de ces réflexions ne sont peut-etre plus valables aujourd'hui, d'autres le sont encore.
Et puis, dépassé, ça veut dire quoi ? Qu'on a forcément mieux dans tous les cas avec une techno plus moderne ? J'aimerais bien y croire. Ce que tu gagnes quelque part sur une techno réfléchie (même vieille), tu le perds généralement ailleurs. La polyvalence et la simplicité d'une redirection d'I/O contre la puissance et l'exclusivité d'une API....
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tu n'as pas l'impression que tu rales parce qu'un logiciel ne répond pas a ton besoin ? Tout ce passage c'est : comment je fais ci ou ça avec ? La réponse est : tu ne le fais pas vu que ce n'est pas fait pour ça.
Tu aurais une lib de gravure avec juste gboolean burn(char* isoname) ça serait le même problème. Ta critique porte sur les fonctionnalités de cdrecord, non pas sur les techniques utilisées par son interface pour communiquer avec.
(..)C'est juste une question de bonne pratique(...)
Oui, dans le but de maintenir le machin et d'en faire quelque chose d'évolutif. Parfois, on fait un truc tout con qui répond juste a un besoin et alors, la bonne pratique est de faire simple. Ensuite, la séparation peut tres bien etre faite, au moins au niveau source. C'est juste que tu n'as pas envie de te taper les contrôles inhérents à la création d'une lib parec que tu ne programme que pour une ligne de commande.
ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général (...)à parser par une application tierce-partie
Il ne t'est jamais venu a l'idée que ce n'etait pas fait pour ? Encore une fois, tu rales parce que tu essayes d'utiliser un outil dans un contexte pour lequel il n'a pas été fait (typiquement, le fait de parser des fichiers config automatiquement alors qu'ils ne sont pas faits pour ça).
Les config XML c'est l'inverse. Avec VI, le XML c'est infect et illisible. Normal ce n'est pas fait pour ça.
Dans un cas c'est documenté, pas dans l'autre.
Si le gars ne documente pas, commande ou lib, tu es dans les deux cas dans la mouise. C'est un probleme de doc, pas de techno.
C'est pas un peu très idiot ?
Pas plus que de transformer un appel interne du front end en un appel à une lib. LA lib traitera aussi les parametres pour s'assurer qu'ils sont valables et accesoirement, les transformera peut-être pour ses besoins internes.
Le principe est le même : c'est une transformation des parametres transmis au frontend pour l'envoyer vers le truc qui va éventuellement les transformer afin d'éxecuter sa tache avec les bons paramètres.
Il n'y a que le chemin technique qui differe. Dans certains cas, c'est plus facile par du code, dans d'autres c'est plus facile via une ligne de commande.
Juste pour la précision (...) je ne vois pas en quoi celà va dans ton sens
Je n'ai cité ça que pour illustrer le fait que, comme mes autres exemples, quand les methodes lègeres sont sorties du panier, elles etaient souvent présentées comme LA solution à tous les problèmes. Comme toujours, on en est revenu et on les considère maintenant que comme un des outils pour gérer un projet, au même titre que les autres méthodes. On choisi de les utiliser ou pas en fonction du contexte du projet, pas uniquement parce que çai mieux (tm).
La ligne de commande comme IPC, n'est pas plus que la librairie, l'interface ultime, même si d'après toi elle a été présentée comme tel. En tous cas, je n'ai jamais affirmé que c'était LA solution, je dis juste qu'il est crétin de la bannir sous prétexte que çai mal (tm).
Oui effectivement, seulement si il a les sources.
Oui evidemment :) De toutes façons, si tu n'as pas les sources, lib ou commande, tu feras très probablement des trucs porky si tu veux étendre les fonctionnalités de l'outil, parce que tu ne pourras faire les ajustements nécessaires dans l'outil pour qu'il prenne en charge tes nouvelles utilisations.
Celà peut être légitime(...)communication privilégié
1- je ne vois pas en quoi les chaines de caractères sont des formats à la con : c'est humainement compréhensible (contrairement à un hash, ou une structure/record ou autre type composite) et ça se génère et gère tres bien dans bon nombre de langage (je ne connais que le C qui rend leur gestion plus délicate).
2- un programme est fait pour être utilisé dans un but et dans un contexte. Il est évident que si ton programme n'est fait QUE pour des machines, il existe d'autres moyens que la ligne de commande et probablement plus adaptés. Maintenant, si tu veux quelque chose d'utilisable par des humains (une commande) et parfois, par des machines, la ligne de commande c'est une possibilité qui peut s'avérer plus interessante que les autres, particulierement dans le cas que j'ai cité : paramétrage d'un processus long et non interactif.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant.
Non, ça joue le morceau que je demande, ça l'arrete quand je n'en veut plus ou quand il est terminé, le tout en mode graphique : ça fait ce pour quoi c'est fait.
il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité.
Dans ce cas, on devrait utiliser une librairie :) Ce n'est pas très malin de passer par la ligne de commande si on veut de l'interactivité durant le traitement. Il me semble que je l'ai déjà dit avant.
Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure...
Non, mon besoin c'est : je selectionne tous les paramêtres de la gravure graphiquement, je clique sur GO et quand c'est fini le frontend me dit "ça marche / ça marche pas" en fonction du résultat : la ligne de commande c'est nickel pour ça.
Si tu as les besoins que tu cites, alors oui, utilises une lib.
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire
Beh si. Il te faut coder ta lib béton parce que l'utilisateur de la lib peut t'envoyer du yahourt. Si je fais un burn(NULL), et que tu ne testes pas dans burn() tes paramètres d'entrée, alors segfault. Si j'ai une fonction burn() identique dans un programme et pas en lib, je n'ai pas besoin de faire ce test, parce que je sais que je n'y enverrais jamais NULL si je sais que j'ai fait le controle en amont.
Evidemment, ce n'est qu'un exemple, mais ce n'est evidemment pas le seul et puisque tu demande un truc indépendant du langage (d'ailleurs, le débordement de buffer ce n'est pas spécifique au C), en voila un autre :
Toujours en restant sur l'exemple de la gravure, tu dois vérifier dans burn() que le device cible existe bien, ou au moins gérer l'erreur si l'utilisateur de la lib envoie n'importe quoi. Si c'est une fonction intégrée un programme complet, ce n'est pas forcément nécessaire si tu as fait le controle en amont (si l'utilisateur n'a qu'un choix limité, par exemple).
De toutes manières c'est hors sujet.
D'ailleurs, il me semble bon de rappeller, au milieu de ce troll, que le sujet n'est pas "la librairie c'est mieux". Le sujet est "c'est abérrant d'utiliser des redirections d'I/O dans des programmes". Mon propos est : "parfois les redirections d'I/O c'est plus adapté qu'une API" et le tien, si je l'ai bien compris est : "dans tous les cas, il devrait y avoir une API et on ne devrait jamais utiliser la redirection I/O comme ipc".
plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Ce ne sont pas que des habitudes : les mecs qui utilisaient ça plutot qu'autre chose le faisaient de manière aussi réfléchie que maintenant. Certaines de ces réflexions ne sont peut-etre plus valables aujourd'hui, d'autres le sont encore.
Et puis, dépassé, ça veut dire quoi ? Qu'on a forcément mieux dans tous les cas avec une techno plus moderne ? J'aimerais bien y croire. Ce que tu gagnes quelque part sur une techno réfléchie (même vieille), tu le perds généralement ailleurs. La polyvalence et la simplicité d'une redirection d'I/O contre la puissance et l'exclusivité d'une API....