Oj: Adicionar opção para análise estrita de número

Criado em 13 nov. 2019  ·  5Comentários  ·  Fonte: ohler55/oj

Oi,

Eu opero várias APIs JSON que usam oj em várias capacidades. Em geral, queremos forçar a análise muito estrita (e usar o modo oj de strict ) para não oferecer suporte acidental a recursos de análise que não poderíamos mais tarde se mudarmos para um diferente biblioteca. Recentemente, oj relaxou a rigidez para a análise de números de duas maneiras. Após essas alterações, elas foram restringidas no modo de compatibilidade json aqui e aqui .

Eu gostaria de poder aplicar esse comportamento (falha em formatos de número que não fazem parte do padrão JSON), mas não vejo outra maneira de ativar esse comportamento nas opções de opções e preferiria o restante de strict configuração. De acordo com os objetivos da documentação do modo estrito , parece que este deve ser o comportamento padrão para strict também, (mas se você concordar, acredito que isso exigiria o lançamento de uma nova versão principal, já que atualmente é permitido). Em qualquer caso, gostaria de poder optar pelo modo de análise mais restrito, talvez por meio de uma opção.

tl; dr: Desejo gerar um erro ao analisar Oj.load('+1.') ou semelhante ao usar o modo strict , como foi o caso < 3.7.1 .

Obrigado por uma grande jóia!

Comentários muito úteis

A versão 3.10.0 inclui uma correção para esse problema.

Todos 5 comentários

Não considerei o modo estrito ao fazer a alteração na análise de número. Eu classificaria isso como um bug. Eu prefiro lidar com isso dessa maneira. Existem outros bugs introduzidos além do + e do . posterior?

@ ohler55 Não estou pessoalmente ciente de nenhum outro bug, mas não fiz nenhum teste diferencial. Eu peguei a mudança lendo o changelog e então dei uma olhada rápida no histórico de commits.

Se você gostaria de lidar com isso como um bug, a decisão é sua - não vai me impactar negativamente, mas é uma mudança semântica que pode potencialmente afetar outras pessoas. Deixo esse tipo de consideração da SemVer ao seu julgamento. Suponho que tratá-lo como uma correção de bug seria consistente com as versões anteriores, como 3.7.4, onde mudou para o modo compat .

Mais uma vez, agradeço seu trabalho árduo nesta joia.

Um pouco lento, mas o branch bug/570 tem a correção.

A versão 3.10.0 inclui uma correção para esse problema.

Ótimo, obrigado!

Esta página foi útil?
0 / 5 - 0 avaliações