Re: anti-pattern NIH

On me reproche des abstractions soit-disant inutiles dans mon framework, mais les commentaires eux-mêmes ne portent essentiellement que sur des abstractions ; c'est difficile d'argumenter dans ces cas là. Il y a néanmoins quelques points concrets qui sont évoqués auxquels je vais tenter de répondre.

Les noms abscons. Je m'en suis justifié plus haut. Et surtout, je ne pense pas que le problème vienne des noms en soi, mais plutôt de l'absence de documentation au sujet des binaires concernés. Je n'aime pas rédiger de la documentation, car je suis très mauvais en cela. Mais j'essaie quand même d'en écrire, tant bien que mal, comme en témoigne le contenu de mon Wiki.

Les fichiers générés contenus dans le VCS ; je pense que tu entends par là le contenu du dépôt mercurial. Les seuls fichiers générés qu'il contient sont les Makefile, et les .h contenant les APIs des backends. Ces fichiers sont générés à l'aide de scripts stockés sur ma machine de développement principale, celle avec laquelle je travaille la plupart du temps. Si je ne mettais pas ces fichiers dans le dépôt, je serais obligé de les régénérer sur chacune des mes autres machines de travail, et donc d'installer ces scripts et leur environnement d'exécution sur ces machines, ce qui est loin d'être évident vu la diversité des machines (il y a là des machines sous Windows, Linux, MacOS, Android et même Maemo...). Donc, j'ai choisi la solution la plus facile et la plus rapide, à savoir de placer ces fichiers dans le dépôt. Il y a aussi un .xml correspondant à l'API d'un backend. A vrai dire, celui-ci n'y a été mis que récemment, à l'occasion de la rédaction de ce journal ; en temps normal, je ne place pas ces fichiers dans le dépôt.

Pour le contenu des Makefile, je ne vois pas le problème, mais je n'y connais à vrai dire pas grand chose sur le sujet. Le cœur du Makefile, qui se situe à la fin du fichier, est tout ce qu'il y a de plus classique (règle de construction du binaire à partir des fichiers objets, règle de construction des fichiers objets à partir des fichiers sources). Le reste, ce n'est que l'adaptation aux particularités des différentes plateformes sur lequel il peut être lancé. Qu'est-ce qui sort donc de l'ordinaire, et par quoi peut-on le remplacer qui soit plus conforme aux standards en la matière ?

xppq. La principale différence avec XSL (mis à part que XPP n'est de loin pas aussi puissant que XSL), c'est que les directives XSL doivent être placées dans un fichier disjoint de celui qui contient le XML sur lequel on va appliquer ces directives, alors que les directives XPP, quant à elles, sont directement placées dans les fichiers XML sur lesquels elles portent. Le principe derrière XPP est le même que celui du préprocesseur C. XSL n'a pas du tout la même approche. A noter que j'utilisais XSL bien avant d'avoir écrit xppq ; je l'ai donc écrit car il répondait à un besoin auquel XSL ne pouvait répondre.

Pour les traductions, je n'utilise pas gettext, car je réutilise le même mécanisme que pour mes fichiers de configuration. Utiliser gettext aurait impliqué un travail de codage supplémentaire, que j'économise avec le système que j'utilise.

Les dates. Je pense que tu te réfères à la bibliothèque DTE. Je l'ai développée pour répondre aux besoins d'un client. Ce dernier devait pouvoir stocker des dates classiques, mais aussi approximatives. Il y a, en effet, certains personnages dont on ne connaît pas avec précision les dates de naissances et/ou de décès. Avec cette bibliothèque, on peut stocker des dates au jour prés, mais aussi seulement au mois, à l'année, à la décennie... prés. Comme le surcoût de cette bibliothèque est négligeable par rapport à celle d'une bibliothèque de gestion de dates classique, j'en ai fait ma bibliothèque standard.

---

Ta réaction à bibliothèque DTE est typiquement celle que je ne comprends pas. Parce certains ne voient pas l'utilité de réimplémenter une telle bibliothèque, ces derniers décrètent que c'est une erreur, sans chercher à comprendre les motivations derrières. Et c'est cette même approche de mon framework en général que l'on retrouve dans les commentaires ; on ne comprend pas, donc, au lieu d'approfondir, ou de demander des éclaircissement au développeur si l'on a pas envie de se plonger dans le code (ce que je comprends tout à fait), on se répand en généralités sans rapports pour discréditer le framework en question.

Quand à ma soi-disant méta-blague, ce n'en est pas une, méta ou non. C'est la réelle motivation qu'il y a derrière mon framework. Je suis un développeur professionnel, et je n'aurais pas développé ce framework si je pouvais développer aussi vite et aussi bien avec d'autres outils. Ceci dit, je suis tout-à-fait prêt à envisager que je me suis fourvoyé, mais, de grâce, appuyez vos écrits avec des exemples concrets ; il s'agit de Logiciel Libre après tout, et les sources sont facilement accessibles (même pas besoin de les télécharger !).

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