Ce qui doit te manquer pour comprendre mon commentaire est qu’il y a eu toute une polémique sur le fait que sur la base de ce que la spécification JSON définit un objet comme "an unordered set of name/value pairs", certains développeurs significatifs de bibliothèque JSON qui faisait référence refusaient catégoriquement et ce pendant de très longues années de considérer l’implémentation optionnelle de la conservation de l’ordre, et c’était une forme d’obstruction puisque c’était une opposition par principe au concept même, et pas simplement un argument du genre « faites-le vous-même, moi je ne perdrai pas de temps là-dessus ». Ça a été un sérieux obstacle au choix d’utiliser le format JSON ou au choix d’utiliser telle bibliothèque qui fait référence. Personnellement j’ai fait face au problème quand j’ai eu besoin de stocker dans des dépôts versionnés des données générées par des outils que j’écrivais. C’est pour ça qu’historiquement mes outils ne génèrent pas du JSON. Je ne sais pas où ça en est, je pourrai reconsidérer la chose. Tout ça est loin dans mes souvenirs je ne sais pas comment retrouver de lien sur le sujet, mais toujours est-il que mes outils en gardent la trace et que ça a donc marqué durablement mes projets et que tant que ces projets vivront, ils témoigneront de ces temps troublés par une cicatrice toujours visible.
Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, et que puisque le second logiciel ne doit pas supposer d’ordre pour fonctionner, le besoin d’implémenter un ordre à la génération du json serait en fait le témoin d’un problème de conception dans le logiciel qui parse.
Mais ça c’est un cas typique de courte-vue et d’assomption fausse sur le fait que les gens n’auront que ce besoin et strictement que ce besoin. Dans la vraie vie les gens développent des tas de besoins dont certains sont tout à fait honorables, comme le fait de stocker des données sérialisées dans un dépôt versionné.
Ce qui est amusant c’est qu’avec la spécification Vulkan est fournit un fichier JSON qui est utilisé pour faire de la validation. Comme toute spécification versionnée, c’est typiquement le genre de fichier qu’on peut vouloir stocker dans un dépôt versionné, et bien que la spécification JSON permette le désordre, conserver l’ordre simplifie vraiment les choses pour les gens, par pour l’outil de validation qui n’en a rien à faire de l’ordre, mais pour les gens, typiquement pour comparer deux commits tu n’aurais pas besoin d’outil dédié. N’en déplaise à ceux qui se cachent derrière la spécification de JSON elle-même pour supposer que ce besoin n’existe pas.
La spec json n’interdît pas de trier les clés de façon déterministe, ni de conserver l’ordre des clés entre une lecture et une écriture.
Exactement, c’est pour cela que faire de l’obstruction sur un besoin qui ne contredit pas la spécification est... surprenant.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: JSON? YAML?’
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 8. Dernière modification le 08 octobre 2020 à 21:37.
Ce qui doit te manquer pour comprendre mon commentaire est qu’il y a eu toute une polémique sur le fait que sur la base de ce que la spécification JSON définit un objet comme "an unordered set of name/value pairs", certains développeurs significatifs de bibliothèque JSON qui faisait référence refusaient catégoriquement et ce pendant de très longues années de considérer l’implémentation optionnelle de la conservation de l’ordre, et c’était une forme d’obstruction puisque c’était une opposition par principe au concept même, et pas simplement un argument du genre « faites-le vous-même, moi je ne perdrai pas de temps là-dessus ». Ça a été un sérieux obstacle au choix d’utiliser le format JSON ou au choix d’utiliser telle bibliothèque qui fait référence. Personnellement j’ai fait face au problème quand j’ai eu besoin de stocker dans des dépôts versionnés des données générées par des outils que j’écrivais. C’est pour ça qu’historiquement mes outils ne génèrent pas du JSON. Je ne sais pas où ça en est, je pourrai reconsidérer la chose. Tout ça est loin dans mes souvenirs je ne sais pas comment retrouver de lien sur le sujet, mais toujours est-il que mes outils en gardent la trace et que ça a donc marqué durablement mes projets et que tant que ces projets vivront, ils témoigneront de ces temps troublés par une cicatrice toujours visible.
Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, et que puisque le second logiciel ne doit pas supposer d’ordre pour fonctionner, le besoin d’implémenter un ordre à la génération du json serait en fait le témoin d’un problème de conception dans le logiciel qui parse.
Mais ça c’est un cas typique de courte-vue et d’assomption fausse sur le fait que les gens n’auront que ce besoin et strictement que ce besoin. Dans la vraie vie les gens développent des tas de besoins dont certains sont tout à fait honorables, comme le fait de stocker des données sérialisées dans un dépôt versionné.
Ce qui est amusant c’est qu’avec la spécification Vulkan est fournit un fichier JSON qui est utilisé pour faire de la validation. Comme toute spécification versionnée, c’est typiquement le genre de fichier qu’on peut vouloir stocker dans un dépôt versionné, et bien que la spécification JSON permette le désordre, conserver l’ordre simplifie vraiment les choses pour les gens, par pour l’outil de validation qui n’en a rien à faire de l’ordre, mais pour les gens, typiquement pour comparer deux commits tu n’aurais pas besoin d’outil dédié. N’en déplaise à ceux qui se cachent derrière la spécification de JSON elle-même pour supposer que ce besoin n’existe pas.
Exactement, c’est pour cela que faire de l’obstruction sur un besoin qui ne contredit pas la spécification est... surprenant.
ce commentaire est sous licence cc by 4 et précédentes