Au risque de sembler condescendant—ce qui n'est réellement pas mon but*—je vais essayer une autre approche.
La discussion semble bloquée parce que nous avons une vision différente. Tu vois le parser json comme une entité théorique, détachée du reste et qui ne devrait obéir qu'aux règles de sa spécification propre indépendemment des conséquences que cela peut avoir. Je vois le parser json comme faisant partie d'un tout et devant donc collaborer avec le reste pour assurer un fonctionnement optimal au système.
Deux exemples de cette dichotomie :
Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.
Si j'étais de mauvaise foi, je dirais que le json est en soi une "structure qui permet de se balader dans l'arbre". Mais surtout, tu mets de côté le fait qu'un parser json n'est jamais utilisé seul. Lorsque tu dis "en faire une structure", c'est donc que c'est le parser qui doit faire un choix de représentation de l'information. Or, ce choix constitue son interface avec le reste du monde. C'est donc le problème du parser que de déterminer et d'appliquer des limites (arbitraires certes) faisant en sorte que cette interface reste utile.
[À propos d'une zip bomb] Oui, un autre très bon exemple, c'est pas le problème de la lib qui dézippe, c'est celui de celui qui l'utilise !
Encore une fois, tu as raison si on observe le décompresseur en vase clos. Après tout, il ne fait que son travail. Pourtant, ton système, lui, sera loin d'avoir un comportement idéal—au contraire, ce sera plutôt une cible idéale. Un décompresseur capable de rejeter les cas totalement hors normes (même si formellement valides) avec une erreur claire sera bien plus utile et correct d'un point de vue global.
Pourquoi est-ce que l'argument que tu dis à propos des temps d'accès ne vaut pas pour l'utilisation de la pile ?
Ça s'applique, justement. Un bon système ne va pas se contenter de supposer qu'il existe dans un monde idéal avec une pile infinie, mais arrêter le massacre à un moment qu'il juge opportun (e.g. trop loin de la "norme" pour être réellement utile).
Pour terminer à propos du JSON : oui, on pourrait écrire des parsers différents. En fait, il semble déjà y en avoir. Mon propos ne réside pas tant dans l'impossibilité de le faire (quoique, soit dit en passant, même ces nouveaux parsers top cool auraient aussi des limites, que d'aucuns pourraient qualifier d'absurdes) mais plutôt dans l'argument général qu'il faudrait toujours pouvoir tout gérer, même les cas à la limite de l'impossible. La simplicité est aussi une belle vertu...
Lorsque je dis qu'un concept n'est pas facile à appréhender, ce n'est pas pour signifier que ceux qui ne le comprennent pas sont des idiots, mais justement pour souligner le fait qu'il est contre-intuitif. Le paradoxe des anniversaires, par exemple, est un concept "pas forcément facile à appréhender". Ça ne signifie pas pour autant que je suis condescendant à l'égard des gens qui ne le saisissent pas de prime abord.
[^] # Re: Intérêt ?
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 8.
Au risque de sembler condescendant—ce qui n'est réellement pas mon but*—je vais essayer une autre approche.
La discussion semble bloquée parce que nous avons une vision différente. Tu vois le parser json comme une entité théorique, détachée du reste et qui ne devrait obéir qu'aux règles de sa spécification propre indépendemment des conséquences que cela peut avoir. Je vois le parser json comme faisant partie d'un tout et devant donc collaborer avec le reste pour assurer un fonctionnement optimal au système.
Deux exemples de cette dichotomie :
Si j'étais de mauvaise foi, je dirais que le json est en soi une "structure qui permet de se balader dans l'arbre". Mais surtout, tu mets de côté le fait qu'un parser json n'est jamais utilisé seul. Lorsque tu dis "en faire une structure", c'est donc que c'est le parser qui doit faire un choix de représentation de l'information. Or, ce choix constitue son interface avec le reste du monde. C'est donc le problème du parser que de déterminer et d'appliquer des limites (arbitraires certes) faisant en sorte que cette interface reste utile.
Encore une fois, tu as raison si on observe le décompresseur en vase clos. Après tout, il ne fait que son travail. Pourtant, ton système, lui, sera loin d'avoir un comportement idéal—au contraire, ce sera plutôt une cible idéale. Un décompresseur capable de rejeter les cas totalement hors normes (même si formellement valides) avec une erreur claire sera bien plus utile et correct d'un point de vue global.
Ça s'applique, justement. Un bon système ne va pas se contenter de supposer qu'il existe dans un monde idéal avec une pile infinie, mais arrêter le massacre à un moment qu'il juge opportun (e.g. trop loin de la "norme" pour être réellement utile).
Pour terminer à propos du JSON : oui, on pourrait écrire des parsers différents. En fait, il semble déjà y en avoir. Mon propos ne réside pas tant dans l'impossibilité de le faire (quoique, soit dit en passant, même ces nouveaux parsers top cool auraient aussi des limites, que d'aucuns pourraient qualifier d'absurdes) mais plutôt dans l'argument général qu'il faudrait toujours pouvoir tout gérer, même les cas à la limite de l'impossible. La simplicité est aussi une belle vertu...