Oui, en ruby ou en PHP aussi, la limite est fixée dans le code.
Vu les valeurs que tu as trouvées (101 et 512), ça ne m’étonne pas.
Je soupçonnerais la même chose pour Rust (128), C/jansson (2049 — note que ton programme indique la valeur pour laquelle ça ne fonctionne plus, 513 par exemple en Perl en laissant la limite par défaut à 512)...
Cela empêche d'utiliser JSON, pour, par exemple représenter un arbre, alors que sans cette limite fixée par les implémentations, le format s'y prêterait très bien.
La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?
S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.
Vois-tu un exemple d’application pour laquelle un arbre très profond (disons avec une profondeur supérieure à 5000) soit une structure adaptée ?
Si oui, la question de pouvoir le représenter pour le stocker, idéalement sous une forme moins sensible à la plateforme qu’une forme binaire, est effectivement intéressante.
Est-ce que les bibliothèques de sérialisation disponibles pour les divers langages gèrent ça mieux que les bibliothèques JSON ? Y a-t-il une représentation (ou à peu près) standard dont les bibliothèques tiennent mieux la route à ce niveau (XML ?) ?
La seule fois où j’ai eu à stocker un arbre (il y a 25 ans ; on trouvait moins de bibliothèques, à l’époque...), j’avais fait un parcours en profondeur et je stockais un nœud par ligne de fichier avec comme indications sa profondeur et sa valeur. Quand on reconstruisait l’arbre, la profondeur indiquait où greffer le nouveau nœud sur la branche courante. D’un point de vue analyse syntaxique, c’est très simple (en tout cas avec les valeurs de mes nœuds, qui l’étaient). Maintenant, cet arbre passerait en JSON, même avec la limite à 100 du parser Ruby...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Intérêt ?
Posté par Arthur Accroc . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 3.
Vu les valeurs que tu as trouvées (101 et 512), ça ne m’étonne pas.
Je soupçonnerais la même chose pour Rust (128), C/jansson (2049 — note que ton programme indique la valeur pour laquelle ça ne fonctionne plus, 513 par exemple en Perl en laissant la limite par défaut à 512)...
La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?
S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.
Vois-tu un exemple d’application pour laquelle un arbre très profond (disons avec une profondeur supérieure à 5000) soit une structure adaptée ?
Si oui, la question de pouvoir le représenter pour le stocker, idéalement sous une forme moins sensible à la plateforme qu’une forme binaire, est effectivement intéressante.
Est-ce que les bibliothèques de sérialisation disponibles pour les divers langages gèrent ça mieux que les bibliothèques JSON ? Y a-t-il une représentation (ou à peu près) standard dont les bibliothèques tiennent mieux la route à ce niveau (XML ?) ?
La seule fois où j’ai eu à stocker un arbre (il y a 25 ans ; on trouvait moins de bibliothèques, à l’époque...), j’avais fait un parcours en profondeur et je stockais un nœud par ligne de fichier avec comme indications sa profondeur et sa valeur. Quand on reconstruisait l’arbre, la profondeur indiquait où greffer le nouveau nœud sur la branche courante. D’un point de vue analyse syntaxique, c’est très simple (en tout cas avec les valeurs de mes nœuds, qui l’étaient). Maintenant, cet arbre passerait en JSON, même avec la limite à 100 du parser Ruby...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone