Сообщение Re[7]: JSON vs BSON: очередное торжество больного воображени от 01.12.2022 19:43
Изменено 01.12.2022 19:48 vsb
Re[7]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, B0FEE664, Вы писали:
νsb>>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
BFE>>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>>Можно пример, который не парсится общепринятым способом?
BFE>1. — парсится, а не должен
BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?
В жаве Double.parseDouble оба значения парсит как положено. new BigDecimal, если хочется без ограничений — тоже парсит.
Не очень понял, почему парсер не должен принимать невалидный вход. Парсер должен работать на валидных входах. Как поступать с невалидным входом это уже вопрос философский. В конкретном данном случае парсить 1. без ошибки это скорей правильно, чем неправильно. Очень полная реализация, конечно, может включать и режим абсолютно строгого парсера. А я бы и комментарии парсил и строки без кавычек.
νsb>>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
BFE>>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>>Можно пример, который не парсится общепринятым способом?
BFE>1. — парсится, а не должен
BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?
В жаве Double.parseDouble оба значения парсит как положено. new BigDecimal, если хочется без ограничений — тоже парсит.
Не очень понял, почему парсер не должен принимать невалидный вход. Парсер должен работать на валидных входах. Как поступать с невалидным входом это уже вопрос философский. В конкретном данном случае парсить 1. без ошибки это скорей правильно, чем неправильно. Очень полная реализация, конечно, может включать и режим абсолютно строгого парсера. А я бы и комментарии парсил и строки без кавычек.
Re[7]: JSON vs BSON: очередное торжество больного воображени
Здравствуйте, B0FEE664, Вы писали:
νsb>>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
BFE>>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>>Можно пример, который не парсится общепринятым способом?
BFE>1. — парсится, а не должен
BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?
В жаве Double.parseDouble оба значения парсит как положено. new BigDecimal, если хочется без ограничений — тоже парсит.
Не очень понял, почему парсер не должен принимать невалидный вход. Парсер должен работать на валидных входах. Как поступать с невалидным входом это уже вопрос философский. В конкретном данном случае парсить 1. без ошибки это скорей правильно, чем неправильно. Очень полная реализация, конечно, может включать и режим абсолютно строгого парсера. А я бы и комментарии парсил и строки без кавычек.
Вот при сериализации нужно генерировать строго валидный JSON, это безусловно.
νsb>>>>Статью не читал, но парсинг JSON-а делается в пару сотен строк, нет там ничего сложного, формат простейший.
BFE>>>Формат чисел задан не общепринятым способом, так что один их парсинг займёт пару сотен строк.
νsb>>Можно пример, который не парсится общепринятым способом?
BFE>1. — парсится, а не должен
BFE>1.0e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 — рапарсится общепринятым способом?
В жаве Double.parseDouble оба значения парсит как положено. new BigDecimal, если хочется без ограничений — тоже парсит.
Не очень понял, почему парсер не должен принимать невалидный вход. Парсер должен работать на валидных входах. Как поступать с невалидным входом это уже вопрос философский. В конкретном данном случае парсить 1. без ошибки это скорей правильно, чем неправильно. Очень полная реализация, конечно, может включать и режим абсолютно строгого парсера. А я бы и комментарии парсил и строки без кавычек.
Вот при сериализации нужно генерировать строго валидный JSON, это безусловно.