Comments 30
Который значительно сложнее и очень хрупкий (из-за значащих отступов).
Смотря что вам нужно от формата сериализации. Кто-то вон на питоне и кофе пишет, на отступы вроде не жалуются. В edn зато разделителей в массивах нет.
Насчет сложности, искренне не понимаю чем yaml сложнее edn. Вроде всё то же самое, вид сбоку.
UFO landed and left these words here
Вы, видимо, не в курсе, что валидный json является в то же время валидным yaml документом?
Я был не в курсе. Забавно. но спорное преимущество. Писать yaml в json'овом формате это странно. Мне лично yaml немного не нравится тем, что в нём я не могу спокойно, как захочется, писать данные, надо строго следить за отступами. Если редактор поддерживает yaml и сам всё контролирует, то круто, но это не всегда так. Конечно в этом и прелесть yaml'а, что все файлы (конфиги) выглядят однообразно и красиво. Но если что-то на коленке протестировать, как пример с тем же curl'ом (где гарантия, что парсеры yaml'а корректно распарсят json-like формат?). Поэтому с json'ом или edn'ом мне кажется будет проще для таких целей.
>> где гарантия, что парсеры yaml'а корректно распарсят json-like формат?
Там же где и гарантия, что они корректно распарсят yaml. Он так устроен, что json является его подмножеством (yaml 1.2).
Если вы не доверяете конкретным реализациям парсера, то это уже другой вопрос.
Я сейчас попробовал найти yaml парсер для джавы, который поддерживает 1.2 и сходу не нашёл. Т.е. для спецификации, которой уже больше 3 лет нет реализации на одном из самых популярных языков? Я могу это понять тем, что это не сильно актуально, т.к. мало кто пользуется этими фичами. И следовательно от того, что они есть ни холодно, ни жарко.
Вообще посмотрел на оф сайте, большинство реализуют 1.0 или 1.1: www.yaml.org/
UFO landed and left these words here
Об этом конечно можно много спорить, но я напишу не для этого а просто чтобы ваше безапеляционное заявление не казалось читателям какой-то общеизвестной истиной а тем чем и является — вашим личным мнением, подкреплённым неизвестно чем.
По мне так yaml гораздо проще, ведь он и задумывался как формат с наибольшей удобочитаемостью и чётким пониманием людьми. Теже значащие отступы гарантируют что структуру человек сможет легко воспринять на глаз, потому что они всегда будут соответствовать семантическому уровню данных в документе. Может вы имеете ввиду что его сложнее парсить? Ну это да, так это проблема парсеров, их всё равно почти никто на коленке не пишет…
Может ли в качестве ключа в мапе быть использован обьект?
А что вы понимаете под объектом? В качестве ключа может использоваться что угодно, в том числе другая мапа. Возможно nil нельзя использовать.
Имел ввиду как раз «другую мапу». При работе с json приходится дико изворачиваться.

Формат интересный, а теперь вдвойне интересный, спасибо!
При работе с json приходится дико изворачиваться.

{"map": {}}


Где тут дикие извороты?

Или вы хотите писать так?

{{} : {}}


Если да, то теперь самому интересно как это будет выглядеть и обрабатываться
Истины ради хочу отметить, что иногда приходится так изголятся, например, когда нужно сериализовать сложный объект в JSON. Ну а объекты в качестве ключей встречаются не так и редко, и предложение нового типа WeakMap тому доказательство.
>edn — формат данных, появившийся из языка clojure.
S-exp приблизительно раз в 10 старше самой clojure а plist'ы для представления данных думаю появились вместе с ними.
Я плохо разбираюсь в истории возникновения лиспов и их синтаксисов. Поэтому я просто написал, что edn пошёл из clojure. Откуда пошёл clojure это другой вопрос, и он тут не раскрывается.
Ну вы различайте все-таки концепцию и конкретные правила конкретного синтаксиса.
Гм, я так расчитывал что хоть в одном более-менее общеизвестном формате появяться back reference.(возможность ссылаться на другой объект внутри документа)
Но в статье про них не упоминается, значит и тут их нет?
В нормальной реализации plist (например в Common Lisp) есть backreference:
'(:param1 #1=1 :param2 2 :param3 #1#)
Нет, и это философская позиция. EDN — формат представления данных, а не объектов и их связей. Backreference бы усложнили понимание, реализацию и сделали бы парсер stateful.
Да, пожалуй вы правы. backreference лучше реализовывать на уровне выше парсера, как-то мне это не приходило в голову
Можно использовать формат UTF8: \u2603.
Вероятно, тут имеется ввиду юникодный литерал, т.е. юникод в целом, а не именно UTF-8. Точно такие символы (четыре шестнадцатеричные цифры) поддерживаются и в JSON, и там тоже о них не говорится, как о UTF-8.

В качестве ключей может выступать любой другой тип.
К слову, в YAML ключи тоже могут быть не скалярного типа. Вероятно, как для YAML, так и для edn большинство реализаций парсера всё таки ограничиваются простыми типами.

Вообще сложно придумать, когда может быть удобнее использовать список, а не вектор.
Имхо, здесь списки по своей природе ближе к типу record, чем к типу vector. Т.е. это типа рекорда, в котором элементы не поименованы. А сложно придумать, потому что и списки и вектора здесь гетерогенные. Для многих языков второе не верно.

Элементы с тегами это весьма клёвая штука. Сам автор в одной из своих презентаций напирает на важность расширяемости для формата. Как edn, так и YAML поддерживают теги, что позволяет регистрировать в формате свои типы. JSON — нет, и теги приходится симулировать.

У меня другое имхо. Для меня вектор и список это 2 очень похожих типа данных с разными характеристиками операций над ними. И я не думаю, что тут список — это record.
Лично мне в edn симпатичен такой простой факт: пары ключи-значения не надо никак разделять. Ключ и значение в мапе определятся чисто по порядку: нечётные элементы это ключи, последующие чётные — их значения. Это очень круто.

С одной стороны мы имеем JSON с его запятой-разделителем и двоеточием внутри пары. Он также не позволяет «висячие» запятые, это означает, что при перестановке-добавлении-удалении элементов легко потерять запятую, или добавить лишнюю.
С другой мы имеем YAML, где всё подвязано на отступы.

Тут нет ни подвязки на разделитель, ни на отступы, да и разделитель внутри пары не нужен. Супер.
Only those users with full accounts are able to leave comments. Log in, please.