Pas tellement étonné de la réponse (connaissant un peu le personnage ;) ).
En fait je comprends ce qu'il veut dire. Il a tendance à ne pas aimer les comportements élitistes et il est vrai que je le suis assez dans cette démarche. Il y a notamment l'élitisme du langage en général et du vocabulaire des professionnels en particulier (dans le cas qui nous concerne). Perso même en tant que développeur, sortir des noms pour tout et n'importe quoi, ça m'insupporte assez. Et allez qu'on va nommer des "design patterns" pour n'importe quel truc de base. Des fois, y a des branquignoles qui savent à peine programmer, mais qui te disent "ah oui faut faire tel pattern". Moi je suis là "mais de quoi il parle?" En fait il parle en général d'un truc super basique que n'importe quel dév aura lu voire écrit dans du code un jour et se sera pas fait chier à nommer (et la personne aurait pu expliquer ce qu'elle voulait dire en mots courants, mais au lieu de cela, va juste te sortir un "nom" que tu es bien sûr censé connaître, sinon c'est toi le branquignole à ses yeux). Donc au lieu de coder, tu vas avoir quelques dévs hipster qui vont disserter pendant 1h dans un blog post pour expliquer et promouvoir un pattern et il deviendra alors primordial de connaître ce terme (j'ai ouï dire que de nos jours, dans des entrevues pour certaines grosses boîtes, on te demande d'expliquer des patterns... juste donnez moi du code pas des mots pour brasser du vent! 🙄 Franchement quand j'entends ça, je suis heureux de pas postuler pour ces entreprises).
En fait j'ai un apriori négatif sur le besoin de donner des noms compliqués à des trucs simples qu'on pourrait dire en français (ou anglais ici!). Alors je dis pas que c'était ton cas, tu veux juste donner un nom générique assez commun dans le milieu. C'est aussi ce que beaucoup de dévs font quand ils veulent juste nommer un concept. Mais ça donne tout de même matière à réflexion sur le besoin de nommer différemment que le langage ne le permet plus simplement, avec des mots que tous comprennent (même les non-experts et les non-natifs anglais). Et moi c'est ainsi que je comprends sa réponse.
Par contre, je suis un peu plus étonné de la justification donnée. Je pensais (vraiment) que GEGL (qui veut dire pour rappel "GEneric Graphical Library") était une bibliothèque de programmation "générique" pour la manipulation et le traitement des images (en tout cas, c'est comme ça qu'elle est présentée sur l'article wikipedia dédié).
On utilise beaucoup l'introspection dans GIMP, et dans GEGL aussi. Donc notamment cela nous permet de générer des GUI à partir juste d'une opération GEGL (sans aucun code spécifique à cette opération). GIMP fait cela par défaut pour n'importe quelle opération (si quelqu'un ajoute une opération personnelle, GIMP la verra et générera une GUI dans GIMP même; c'est extrêmement puissant comme pouvoir). Maintenant on peut aussi créer des interfaces plus avancées et spécifiques. On le fait pour certaines opérations quand on pense qu'elles méritent mieux que ce que l'interface entièrement introspectée propose. Néanmoins même là, on va beaucoup utiliser l'introspection pour les termes, descriptions, etc. Y a-t-il en effet réellement un besoin de nommer différemment les mêmes choses dans l'API pour dév et dans l'interface graphique? N'est-ce pas mieux d'avoir des termes bien compréhensibles en anglais pour tous?
C'est aussi ça la généricité. Avoir une interface qui marche aussi bien pour le CLI, le code, des interfaces graphiques...
Notons que comme je disais, on utilise ça pas mal dans GIMP. Dernièrement j'ai aussi implémenté assez massivement des capacités d'introspection et de génération d'interface graphique pour les plug-ins (qui n'ont alors pas besoin de long code GTK; quelques dizaines de lignes de code et on a une interface équivalent à 600 lignes de GTK → je rigole pas, c'est en gros le ratio qu'on a eu quand j'ai porté le plug-in JPEG sur cette nouvelle API). Là aussi, les plug-ins vont déclarer des procédures avec des paramètres et des descriptions, qui vont servir autant d'interface de programmation (comme des procédures qui pourront être appelés depuis d'autres plug-ins par exemple) que de textes pour une GUI.
Apparemment, c'est donc plutôt une bibliothèque de traitement d'images destinée à être appelée uniquement depuis des interfaces graphiques ? C'est pas très vendeur :)
Pourquoi cela ne pourrait pas être les 2? 🙂
En fait, c'est même très clairement les 2 dans notre cas!
Et si ce n'est pas le cas (ce que je crois), pourquoi les noms des paramètres des fonctions devraient être forcément les mêmes que les noms des widgets que l'on présente à l'utilisateur d'une UI ?
Je renverse la question: pourquoi cela devrait-il être différent? Après tout, pourquoi un nom ou une description serait-elle bonne dans un cas mais pas dans l'autre? Si un nom décrit bien un paramètre en API, elle le décrirait aussi bien en GUI. 😉
Mais bon, j'admets que je chipote un peu :)
Je pense aussi. 😛
Perso je connaissais pas ce terme. Quand je regarde une opération, je regarde ce qu'elle fait, essaie de comprendre son algorithme/code, me documente... comment s'appelle tel ou tel paramètre, de toutes façons, je l'aurai oublié 5 minutes après (mais je me rappellerai le code et la logique longtemps car c'est ça qui m'intéresse dans le traitement d'image, pas les noms!). Sincèrement je saurais déjà même plus redire de tête le nom que tu as donné ou celui actuel sans scroller pour vérifier (je rigole pas). Et ce même si c'est le sujet principal de notre discussion! Par contre, je me rappelle que l'on parle d'un paramètre pour décider comment considérer les pixels hors des bords de l'image d'entrée. Ça me suffit. Comment ça s'appelle dans l'API, de toutes façons, je revérifierai encore lorsque j'aurai besoin de l'utiliser.
Enfin bon, pour moi, je pense que ça a du sens de rajouter le terme que tu proposes dans la description (c'est ce que je propose) puisque c'est effectivement un nommage classique, comme ça ceux qui connaissent feront le rapprochement en effet. Mais ça ne me gêne pas plus que ça que la propriété n'ait pas ce nom en principal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Greffon G'MIC pour GIMP 2.10.28
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 4.
En fait je comprends ce qu'il veut dire. Il a tendance à ne pas aimer les comportements élitistes et il est vrai que je le suis assez dans cette démarche. Il y a notamment l'élitisme du langage en général et du vocabulaire des professionnels en particulier (dans le cas qui nous concerne). Perso même en tant que développeur, sortir des noms pour tout et n'importe quoi, ça m'insupporte assez. Et allez qu'on va nommer des "design patterns" pour n'importe quel truc de base. Des fois, y a des branquignoles qui savent à peine programmer, mais qui te disent "ah oui faut faire tel pattern". Moi je suis là "mais de quoi il parle?" En fait il parle en général d'un truc super basique que n'importe quel dév aura lu voire écrit dans du code un jour et se sera pas fait chier à nommer (et la personne aurait pu expliquer ce qu'elle voulait dire en mots courants, mais au lieu de cela, va juste te sortir un "nom" que tu es bien sûr censé connaître, sinon c'est toi le branquignole à ses yeux). Donc au lieu de coder, tu vas avoir quelques dévs hipster qui vont disserter pendant 1h dans un blog post pour expliquer et promouvoir un pattern et il deviendra alors primordial de connaître ce terme (j'ai ouï dire que de nos jours, dans des entrevues pour certaines grosses boîtes, on te demande d'expliquer des patterns... juste donnez moi du code pas des mots pour brasser du vent! 🙄 Franchement quand j'entends ça, je suis heureux de pas postuler pour ces entreprises).
En fait j'ai un apriori négatif sur le besoin de donner des noms compliqués à des trucs simples qu'on pourrait dire en français (ou anglais ici!). Alors je dis pas que c'était ton cas, tu veux juste donner un nom générique assez commun dans le milieu. C'est aussi ce que beaucoup de dévs font quand ils veulent juste nommer un concept. Mais ça donne tout de même matière à réflexion sur le besoin de nommer différemment que le langage ne le permet plus simplement, avec des mots que tous comprennent (même les non-experts et les non-natifs anglais). Et moi c'est ainsi que je comprends sa réponse.
On utilise beaucoup l'introspection dans GIMP, et dans GEGL aussi. Donc notamment cela nous permet de générer des GUI à partir juste d'une opération GEGL (sans aucun code spécifique à cette opération). GIMP fait cela par défaut pour n'importe quelle opération (si quelqu'un ajoute une opération personnelle, GIMP la verra et générera une GUI dans GIMP même; c'est extrêmement puissant comme pouvoir). Maintenant on peut aussi créer des interfaces plus avancées et spécifiques. On le fait pour certaines opérations quand on pense qu'elles méritent mieux que ce que l'interface entièrement introspectée propose. Néanmoins même là, on va beaucoup utiliser l'introspection pour les termes, descriptions, etc. Y a-t-il en effet réellement un besoin de nommer différemment les mêmes choses dans l'API pour dév et dans l'interface graphique? N'est-ce pas mieux d'avoir des termes bien compréhensibles en anglais pour tous?
C'est aussi ça la généricité. Avoir une interface qui marche aussi bien pour le CLI, le code, des interfaces graphiques...
Notons que comme je disais, on utilise ça pas mal dans GIMP. Dernièrement j'ai aussi implémenté assez massivement des capacités d'introspection et de génération d'interface graphique pour les plug-ins (qui n'ont alors pas besoin de long code GTK; quelques dizaines de lignes de code et on a une interface équivalent à 600 lignes de GTK → je rigole pas, c'est en gros le ratio qu'on a eu quand j'ai porté le plug-in JPEG sur cette nouvelle API). Là aussi, les plug-ins vont déclarer des procédures avec des paramètres et des descriptions, qui vont servir autant d'interface de programmation (comme des procédures qui pourront être appelés depuis d'autres plug-ins par exemple) que de textes pour une GUI.
Pourquoi cela ne pourrait pas être les 2? 🙂
En fait, c'est même très clairement les 2 dans notre cas!
Je renverse la question: pourquoi cela devrait-il être différent? Après tout, pourquoi un nom ou une description serait-elle bonne dans un cas mais pas dans l'autre? Si un nom décrit bien un paramètre en API, elle le décrirait aussi bien en GUI. 😉
Je pense aussi. 😛
Perso je connaissais pas ce terme. Quand je regarde une opération, je regarde ce qu'elle fait, essaie de comprendre son algorithme/code, me documente... comment s'appelle tel ou tel paramètre, de toutes façons, je l'aurai oublié 5 minutes après (mais je me rappellerai le code et la logique longtemps car c'est ça qui m'intéresse dans le traitement d'image, pas les noms!). Sincèrement je saurais déjà même plus redire de tête le nom que tu as donné ou celui actuel sans scroller pour vérifier (je rigole pas). Et ce même si c'est le sujet principal de notre discussion! Par contre, je me rappelle que l'on parle d'un paramètre pour décider comment considérer les pixels hors des bords de l'image d'entrée. Ça me suffit. Comment ça s'appelle dans l'API, de toutes façons, je revérifierai encore lorsque j'aurai besoin de l'utiliser.
Enfin bon, pour moi, je pense que ça a du sens de rajouter le terme que tu proposes dans la description (c'est ce que je propose) puisque c'est effectivement un nommage classique, comme ça ceux qui connaissent feront le rapprochement en effet. Mais ça ne me gêne pas plus que ça que la propriété n'ait pas ce nom en principal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]