Вопрос по программированию

[birdwatcher]

{"PI": 3.14159, "PI": 5.0}
Кто читал книгу "Дизайн и эволюция языка Джаваскрипт", там объясняется, почему вот это - валидный JSON? Какая от этого может быть польза, кроме вреда?

Comments

[morfizm.livejournal.com]

Я не читал, но мнение имею. Это валидный JSON со значением PI = 5.0. Команды интерпретируются слева направа сверху вниз, последовательно. Кто сам себе злобный буратино и генерирует такие смешные JSON'ы, overwrite'ящие предыдущие значения, сам виноват.

[morfizm.livejournal.com]

Ключевая идея к понимаю, что это валидный джейсон состоит в том, что джейсон это не сериализованная структура данных, как может показаться на первый взгляд, а всего лишь код на javascript.

[birdwatcher.livejournal.com]

А почему полезно парсить заведомо бессмысленный код без даже предупреждений?

[morfizm.livejournal.com]

А откуда парсер знает, что он бессмысленный? Может быть, overwritten значения используются в качестве полезных комментариев? или, скажем, хранят полезную историю последовательных модификаций?

[birdwatcher.livejournal.com]

Почему полезно не иметь синтаксиса для комментариев - это еще один вопрос, смежный.

[morfizm.livejournal.com]

В ответ на это, конечно же, есть смежный вопрос с другой стороны: почему полезно не менять формат, если его можно не менять.

[birdwatcher.livejournal.com]

Так это же новый стандарт, который сразу так сделали в полном объеме. Нельзя объяснить желанием совместимости с чем-то старым.

[morfizm.livejournal.com]

JSON? Я не изучал историю детально, но я сомневаюсь, мне кажется, он всё-таки естественно проэволюционировал из javascript'а (который долгое время был скриптовой поделкой, которую никто не рассматривал всерьёз).

Мне кажется, надо стараться видеть в людях лучшее, и при прочих равных предпочитать объяснения, не основанные на людских пороках (таких как невнимательность, пофигизм, глупость, сладкое садистское желание испортить жизнь инженерам из будущего, которые будут ковырять баги и краевые случаи, и т.п.)

[birdwatcher.livejournal.com]

Я именно подозреваю лучшее, даже спросил - может, кто знает, в чем оно заключается.

[morfizm.livejournal.com]

Я думаю, причины историчекие или compatibility.

Могу придумать причину "чтобы проще было написать парсер" (не нужно проверять на уникальность ключей, типа, сортировать или хэшировать), но это какая-то очень слабая и натянутая причина, мне трудно в неё поверить.

[morfizm.livejournal.com]

Может быть есть какой-то странный юс-кейс, когда намного удобнее дописывать новые значения в конец, таким образом эффективно изменяя старые, но при этом редактировать всё целиком накладно или невозможно в данной ситуации. Конкретику мне придумать сложно.

[birdwatcher.livejournal.com]

Да ну. Не может быть, что об этом думали.

[freedom_of_sea.livejournal.com]

если JSON это код то в нем должны поддерживаться комментарии

[dohlaja-sova.livejournal.com]

прицепом тот же вопрос по поводу присваивания вместо сравнения.

[jsn.livejournal.com]

Ну очевидно же. Для реализации парсера, живущего в тяжёлых условиях (мало памяти и/или CPU clocks), которому из-за этого тяжело проверять уникальность.

[birdwatcher.livejournal.com]

Шутите, надеюсь?

[jsn.livejournal.com]

Нет, совершенно. Более того, это типа общее место.

[birdwatcher.livejournal.com]

Как же это может быть? Парсер все равно должен развернуть всю структуру и каждый атом положить на свое место. И при этом у него не хватает сил посмотреть, что на данном месте уже что-то лежит? Одну JNZ инструкцию сэкономили?

[jsn.livejournal.com]

Парсер может быть stream, при этом он ничего не разворачивает, только выдает a sequence of events (ну, однобитный стек он может держать для валидации, но это совсем не "разворачивает"). Вот пример парсера (http://zserge.com/jsmn.html), который хоть и как бы разворачивает, но делает это без e.g. malloc-ов и ничего не зная о таких стурктурах данных, как hash и set.

[birdwatcher.livejournal.com]

Хм, про него говорят, что он вообще ошибки не детектирует. Jsmn is missing [...] but instead is designed to be robust (it should work fine even with erroneous data). Т.е. он и так уже нестандартный. Если бы мой пример в стандарте был заявлен как erroneous, на качестве jsmn это бы не сказалось.

[jsn.livejournal.com]

Ну да, so what? На качестве валидирующих парсеров с архитектурами такого типа сказалось бы очевидным образом.

[birdwatcher.livejournal.com]

Ну, интересно, есть в результате, или нет. Обычно, когда в стандарте какая-то на первый взгляд шокирующая глупость, то можно получить объяснение вида "к сожалению, иначе широко распространенный X сломался бы".