• [^] # Re: un seul, vraiment ? :-)

    Posté par (site web personnel) . En réponse au journal xppq, ou une autre approche de la gestion des arguments de la ligne de commande.... Évalué à 3.

    Salut,

    Salut !

    Si je comprend bien, tu poses xppq en « concurrent » de solutions comme getopt ou autre moyen de facilement gérer des paramètres en ligne de commande.

    Pas tout à fait. xppq, c'est juste un préprocesseur XML. J'ai écris ce journal pour signaler que c'est le successeur de feu xppq, et j'en ai profité pour parler de ce nouveau système de gestion des arguments de la ligne de commande, car c'est le premier utilitaire que je publie qui l'implémente. Mais comme tous les autres utilitaires que je publierais seront, à l'instar de expp, basés sur le framework Epeios, ils implémenteront également ce système de gestion des arguments de la ligne de commande. xppq n'est pas plus lié à ce système que ne le seront ces autres utilitaires.

    Ceci dit, j'ai effectivement codé ce système pour remplacer celui que j’avais précédemment codé et qui présentait de très fortes similitudes avec getopt. Dans ce sens, ce système peut effectivement être vu comme un concurrent à getopt.

    Donc, c'est un outil (lib ?) plus à destination d'un développeur que d'un utilisateur, même si de par son design, l'utilisateur a la possibilité aussi de changer des trucs ?

    Non, même pas. Pour l'instant, j'ai juste parlé de ce système pour le faire connaître, et j'en ai parlé en conjonction avec xppq pour mettre en évidence que ce n'est pas juste un concept, mais qu'il en existe bel et bien une implémentation fonctionnelle.

    Actuellement, il n'existe pas de bibliothèque, en tant que telle, dédié à ce système. Ce système n'existe qu'en tant que fonctionnalité du framework Epeios. Mais il est bien entendu envisageable d'isoler le code dédié à ce système pour le mettre à disposition sous forme de bibliothèque indépendante. C'est en partie pour éventuellement susciter ce genre de démarche et pour en juger l'opportunité que ce journal a été écrit.

    Et donc, ce fichier de configuration, il doit accompagné le logiciel distribué ? Il se situe où dans l'arborescence du système ? Chez l'utilisateur ou au niveau système ? Et le logiciel, il contient quoi comme type de code pour « utiliser » les paramètres ? Il dépend de ta lib ? C'est une lib ou pas en fait ? xppq est utilisé plutôt ? Comment il fait le lien avec le code du logiciel ? process c'est un exécutable classique ? qui dépend d'une lib xppq pour quand même lire les valeurs des arguments ?

    Comme écrit plus haut, xppq n'est lié à ce système que parce qu'il est basé sur le framewok Epeios. En l'état, pour mettre en œuvre ce système de gestion des arguments de la ligne de commande, c’est tout le framework qu'il faut mettre en œuvre, ce qui implique une approche du développement en C++ (qui est le langage dans lequel est codé le framework Epeios) en particulier et du développement en général qui sort des sentiers battus.

    Bon, tu vois, j'ai pas tout compris, c'est pas clair pour moi :)

    Ça ne m’étonne pas ; je n'ai jamais été très doué pour écrire de la documentation...

    Question bonus : pour moi la différence entre paramètre et argument, c'est que le paramètre c'est ce que tu déclare une fois pour toute en disant « ceci est un paramètre de mon programme » et un argument c'est une instantiation d'un paramètre dans une utilisation particulière : « j'appelle mon programme avec ceci comme argument (sous-entendu pour un paramètre particulier) ».
    C'est comme ça que tu le vois ? J'ai l'impression que non puisque tu appelles « arguments » ce que tu mets dans le fichier de configuration alors que ce ne sont pas des arguments selon la définition que j'en ai... Ton avis ? :)

    Mon emploi de l'un ou l'autre terme est plus une question de feeling que le fruit d'une véritable réflexion. Je pense que, pour l'idée que je m'en fais, ces deux termes sont assez interchangeables...

    Zelbinium: pour la génération qui crée, pas celle qui scrolle...