On peut aussi penser à des "plug-ins" qui n'ont pas l'inconvénient d'être requis ni de consommer de la mémoire pour rien.
À noter pour répondre au détracteur des solutions à base de composition de flux E/S que la sérialisation qu'impose des simples flux n'est pas très pratique, certes, mais est tout de même le fondement du système X Window qui permet de faire des choses interressantes assez facilement. Cela permet de relativiser sur "l'horreur" que constitue l'interfacage graphique de programmes ligne de commande (techniquement on déplace juste le niveau du protocole d'échange ce qui implique entre autre qu'il faut parser au cas par cas... génant mais pas rédibitoire et pas forcement synonyme de perte d'informations (dépend de l'application bien sûr)), d'autant que l'horreur en question à l'aventage de ses inconvénients ;) : base du code parfaitement identique. Ce point peut sembler trivial par rapport à des biblio avec une API bien faite, mais dans certains cas ca pourrait faciliter les choses si de nombreuses différentes utilisation de l'API de la solution "propre" peuvent produire des résultats proches mais différents, ce qui ammene une nouvelle source potentielle de problème (cas vécu). Une autre solution est de faire une API d'interface entre la biblio et l'interface pour gérer carrement des scénarios d'utilisation, mais c'est chiant à écrire et on se retrouve avec une solution pas forcement plus simple, finalement.
Enfin dernier avantage de l'interfacage de CLI par une surcouche (ici on va s'éloigner un peu du graphique) : la possibilité de creer des scriptages extrement rapidement à divers niveaux (parse d'E/S d'un prog interactif ou enchainement de programmes non interactifs) et très simplement alors qu'aucune intégration n'existe à priori entre la solution de scriptage et les programmes à scripter et qu'une solution équivalente utilisant une intégration de plus bas niveau serait beaucoup plus longue à écrire (cas aussi vécu :)
Donc pour moi le bilan est mitigé entre l'interfacage à la barbarre et la solution "propre" ;)
Comme partout, il n'y a pas un coté tout blanc et un coté tout noir, et il convient de voir les avantages et inconvénients de chacuns. Il me semble normal qu'une personne habitué aux CLI se tournera vers des solution de filtrage / interface de flux E/S, alors qu'une personne habitué aux GUI se tournera vers une solution a base d'integration de briques (quelquesoit leur implémentation) ce qui a pour effet de bord d'interdire l'acces a l'utilisateur aux échanges entre les dites briques et de créer un système de type boite noire.
[^] # Re: mon avis.
Posté par Guillaume Knispel . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 2.
À noter pour répondre au détracteur des solutions à base de composition de flux E/S que la sérialisation qu'impose des simples flux n'est pas très pratique, certes, mais est tout de même le fondement du système X Window qui permet de faire des choses interressantes assez facilement. Cela permet de relativiser sur "l'horreur" que constitue l'interfacage graphique de programmes ligne de commande (techniquement on déplace juste le niveau du protocole d'échange ce qui implique entre autre qu'il faut parser au cas par cas... génant mais pas rédibitoire et pas forcement synonyme de perte d'informations (dépend de l'application bien sûr)), d'autant que l'horreur en question à l'aventage de ses inconvénients ;) : base du code parfaitement identique. Ce point peut sembler trivial par rapport à des biblio avec une API bien faite, mais dans certains cas ca pourrait faciliter les choses si de nombreuses différentes utilisation de l'API de la solution "propre" peuvent produire des résultats proches mais différents, ce qui ammene une nouvelle source potentielle de problème (cas vécu). Une autre solution est de faire une API d'interface entre la biblio et l'interface pour gérer carrement des scénarios d'utilisation, mais c'est chiant à écrire et on se retrouve avec une solution pas forcement plus simple, finalement.
Enfin dernier avantage de l'interfacage de CLI par une surcouche (ici on va s'éloigner un peu du graphique) : la possibilité de creer des scriptages extrement rapidement à divers niveaux (parse d'E/S d'un prog interactif ou enchainement de programmes non interactifs) et très simplement alors qu'aucune intégration n'existe à priori entre la solution de scriptage et les programmes à scripter et qu'une solution équivalente utilisant une intégration de plus bas niveau serait beaucoup plus longue à écrire (cas aussi vécu :)
Donc pour moi le bilan est mitigé entre l'interfacage à la barbarre et la solution "propre" ;)
Comme partout, il n'y a pas un coté tout blanc et un coté tout noir, et il convient de voir les avantages et inconvénients de chacuns. Il me semble normal qu'une personne habitué aux CLI se tournera vers des solution de filtrage / interface de flux E/S, alors qu'une personne habitué aux GUI se tournera vers une solution a base d'integration de briques (quelquesoit leur implémentation) ce qui a pour effet de bord d'interdire l'acces a l'utilisateur aux échanges entre les dites briques et de créer un système de type boite noire.