Une chose est de ne pas prendre en compte une fonctionnalité dont on a pas besoin lorsqu’on conçoit un outil pour un besoin très spécifique, une autre chose est d’empêcher que cet outil puisse servir à wat mille autres besoins en refusant que soit implémenté un comportement optionnel qui n’a aucun impact sur le design et le fonctionnement initial et le besoin très spécifique de départ.
Si {"a":2, "b":3} est égal à {"b":3, "a": 2} dans le besoin initial, ça ne casse rien de permettre de produire {"b":3, "a": 2} dès le départ pour ceux qui ont ce besoin indépendamment des besoins pour lequel JSON a été conçu. L’outil qui testera l’égalité n’a pas besoin d’être modifié, à aucun moment. Ça ouvre des perspectives, mais ça ne casse rien, ça ne modifie pas le format, la compatibilité est totale...
La question n’est pas que le comportement se tienne dans son contexte de départ, mais qu’une opportunité qui n’a aucun impact sur le contexte de départ ne soit pas permise, quand la demande est simple, bien expliquée, et facilement justifiable, et que le coût est mineur (et totalement absent pour le contexte de départ).
Par exemple avec pytoml, tu peux décider du constructeur de dictionnaire: {} ou OrderedDict(). Ça n’a aucun impact sur le format. Aucun outil tiers pytoml n’a à être modifié.
Puisque justement JSON est conçu pour fonctionner indépendamment de l’ordre, ordonner des données JSON n’a aucun impact sur son fonctionnement. On peut dire que JSON est précisément conçu pour ne pas être affecté par le fait que les données soient ordonnées. Donc quelqu’un qui produit des données ordonnées et veut parser ces données peut choisir JSON : JSON lui garantit déjà que les données sont correctement parsées bien qu’elles soient ordonnées. Alors, vraiment, rien ne justifie de s’opposer à la reproductibilité optionnelle de l’ordre des données dans la production de fichier JSON.
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é à 3.
Une chose est de ne pas prendre en compte une fonctionnalité dont on a pas besoin lorsqu’on conçoit un outil pour un besoin très spécifique, une autre chose est d’empêcher que cet outil puisse servir à wat mille autres besoins en refusant que soit implémenté un comportement optionnel qui n’a aucun impact sur le design et le fonctionnement initial et le besoin très spécifique de départ.
Si
{"a":2, "b":3}est égal à{"b":3, "a": 2}dans le besoin initial, ça ne casse rien de permettre de produire{"b":3, "a": 2}dès le départ pour ceux qui ont ce besoin indépendamment des besoins pour lequel JSON a été conçu. L’outil qui testera l’égalité n’a pas besoin d’être modifié, à aucun moment. Ça ouvre des perspectives, mais ça ne casse rien, ça ne modifie pas le format, la compatibilité est totale...La question n’est pas que le comportement se tienne dans son contexte de départ, mais qu’une opportunité qui n’a aucun impact sur le contexte de départ ne soit pas permise, quand la demande est simple, bien expliquée, et facilement justifiable, et que le coût est mineur (et totalement absent pour le contexte de départ).
Par exemple avec pytoml, tu peux décider du constructeur de dictionnaire:
{}ouOrderedDict(). Ça n’a aucun impact sur le format. Aucun outil tiers pytoml n’a à être modifié.Puisque justement JSON est conçu pour fonctionner indépendamment de l’ordre, ordonner des données JSON n’a aucun impact sur son fonctionnement. On peut dire que JSON est précisément conçu pour ne pas être affecté par le fait que les données soient ordonnées. Donc quelqu’un qui produit des données ordonnées et veut parser ces données peut choisir JSON : JSON lui garantit déjà que les données sont correctement parsées bien qu’elles soient ordonnées. Alors, vraiment, rien ne justifie de s’opposer à la reproductibilité optionnelle de l’ordre des données dans la production de fichier JSON.
ce commentaire est sous licence cc by 4 et précédentes