J’attends toujours un exemple d’application réelle utilisant un arbre dont la représentation en JSON ne passe pas avec les analyseurs actuels.
J’aurais pensé que quelqu’un en trouverait peut-être un au moins pour la limite la plus basse par défaut de 100 (un petit effort !), mais j’attends toujours...
Sinon, que les analyseurs JSON ne puissent pas lire un fichier produit dans une démarche malveillante, de test ou artistique, mais sans utilité réelle, ça ne m’empêchera pas de dormir (surtout si ça ne concerne pas ceux de mes langages de prédilection). Il y a des trucs qui m’ennuient plus en informatique (l’abandon du système de fichiers Intermezzo, par exemple, ou Berkeley DB*).
Note : si on a un arbre de plus de 100 niveaux qui tient en mémoire, il est fortement déséquilibré (c’est vrai que j’ai oublié ce cas dans mes commentaires précédents) ou beaucoup de nœuds sont le seul nœud fils de leur nœud parent. Un arbre correspondant au second cas peut être compacté en regroupant ces nœuds avec leur nœud parent.
Un petit schéma (ASCII parce que c’est plus simple — je sais que c’est moche), pour éclairer le principe :
e
/
d e
/ \ /
c f bcd
/ / \
b devient a f
/ \
a g
\
g
Donc, il reste à trouver l’exemple d’une application ayant l’utilité d’un arbre d’une profondeur de plus de 100 (par rapport à la limite par défaut la plus basse) voire 900 (par rapport à la limite de récursion sur Python si elle n’est pas facilement relevable, sinon encore plus) fortement déséquilibré et dont un rééquilibrage fausse le sens.
Cela dit, je n’exclus pas complètement qu’un développeur se retrouve un jour dans ce cas. La page de lovasoa pourrait alors lui être utile... si elle distinguait pour tous les langages ou bibliothèques la limite par défaut et la limite maximale.
* Si je voulais râler contre une brique logicielle, ce serait la base Berkeley DB.
Ton serveur OpenLDAP est arrêté brusquement (coupure électrique...) alors qu’il était bien pépère à ne faire que des opérations de lecture sur son backend bdb et c’est hyper grave, il faut reconstruire la base en suivant une doc imbitable. Merde !
Il y a aussi le cas où un fichier Berkeley DB perdu au fin fond du profil Firefox est corrompu et où Firefox ne démarre plus, sans explication pertinente (heureusement, c’est rare ; Firefox ne doit pas les garder ouverts en lecture...).
Berkeley DB n’est à la fois pas adaptée pour une grosse charge et pénible à gérer pour une faible charge. Malheureusement des logiciels l’utilisent...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # J’attends toujours un exemple...
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 2.
Mauvaise foi ? De la part de qui ?
J’attends toujours un exemple d’application réelle utilisant un arbre dont la représentation en JSON ne passe pas avec les analyseurs actuels.
J’aurais pensé que quelqu’un en trouverait peut-être un au moins pour la limite la plus basse par défaut de 100 (un petit effort !), mais j’attends toujours...
Sinon, que les analyseurs JSON ne puissent pas lire un fichier produit dans une démarche malveillante, de test ou artistique, mais sans utilité réelle, ça ne m’empêchera pas de dormir (surtout si ça ne concerne pas ceux de mes langages de prédilection). Il y a des trucs qui m’ennuient plus en informatique (l’abandon du système de fichiers Intermezzo, par exemple, ou Berkeley DB*).
Note : si on a un arbre de plus de 100 niveaux qui tient en mémoire, il est fortement déséquilibré (c’est vrai que j’ai oublié ce cas dans mes commentaires précédents) ou beaucoup de nœuds sont le seul nœud fils de leur nœud parent. Un arbre correspondant au second cas peut être compacté en regroupant ces nœuds avec leur nœud parent.
Un petit schéma (ASCII parce que c’est plus simple — je sais que c’est moche), pour éclairer le principe :
Donc, il reste à trouver l’exemple d’une application ayant l’utilité d’un arbre d’une profondeur de plus de 100 (par rapport à la limite par défaut la plus basse) voire 900 (par rapport à la limite de récursion sur Python si elle n’est pas facilement relevable, sinon encore plus) fortement déséquilibré et dont un rééquilibrage fausse le sens.
Cela dit, je n’exclus pas complètement qu’un développeur se retrouve un jour dans ce cas. La page de lovasoa pourrait alors lui être utile... si elle distinguait pour tous les langages ou bibliothèques la limite par défaut et la limite maximale.
* Si je voulais râler contre une brique logicielle, ce serait la base Berkeley DB.
Ton serveur OpenLDAP est arrêté brusquement (coupure électrique...) alors qu’il était bien pépère à ne faire que des opérations de lecture sur son backend bdb et c’est hyper grave, il faut reconstruire la base en suivant une doc imbitable. Merde !
Il y a aussi le cas où un fichier Berkeley DB perdu au fin fond du profil Firefox est corrompu et où Firefox ne démarre plus, sans explication pertinente (heureusement, c’est rare ; Firefox ne doit pas les garder ouverts en lecture...).
Berkeley DB n’est à la fois pas adaptée pour une grosse charge et pénible à gérer pour une faible charge. Malheureusement des logiciels l’utilisent...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone