Комментарии 27
Чтобы что?
Это проще для обывателя
А что за обыватели у вас в качестве целевой аудитории? Они знают про null или 36-ричную систему исчисления?
И что случилось с датой-временем?
или 36-ричную систему исчисления?
На мой вкус это тут наименее спорная часть, удобно же.
36-ричная система вполне себе ОК в некоторых специфичных случаях, напр Date.now().toString(36) даёт таймстамп как ascii-строку в 8 символов (до 2059 года). Это иногда лучше подходит, чем число – в localStorage больше поместится если туда таймсерии например кладутся, или как часть составного ключа в БД, или в json если сериализуется массово, а надо место экономить.
Но в данном примере 36-ричное число — это формат сериализации, который может быть любым. На уровне формата данных это просто строка. Для пользователя не важно, что это именно число в 36-ричной системе.
формат сериализации <...> это просто строка. Для пользователя не важно, что это именно число в 36-ричной системе
Да, это представление. Если пользователю удобнее записывать 41215 как 16'a0ff (или 0xa0ff), почему бы не дать ему такую возможность? Если по пути используется js-парсер, почему бы не расширить на все поддерживаемые в js из коробки основания (2…36)?
Мой поинт был не конкретно про основание 36, а про саму фичу, которая легко реализуется и точно имеет применение, хотя и очень ограниченное.
Применение безусловно есть. Но мне кажется, область, где экзотические системы счисления нужны, всё же очень узкая.
где экзотические системы счисления нужны, всё же очень узкая
Конечно. Но я двумя руками за подход, когда кроме decimal нужен ещё и hex, и по пути приходит в голову мысль, что можно же не только основания 10 и 16 делать, а сразу 2…36, и это ничего не будет стоить сверху.
По мне, вполне рациональный подход для нового формата – синтаксическая мелочь, не стоит ничего в смысле затрат на кодинг, но вдруг кому пригодится.
В процессе интеграции обнаружилось, что нам этого формата не хватает, да и некоторые другие его минусы стали проявляться
Вот тут не хватает подробностей
Файлы выходили большимии, в них было много повторящихся шаблонных фрагментов.
Шаблонизатор логично делать отдельно от языка. Jinja2 отлично работает с любым языком. И понятный при этом.
В теории у внешнего шаблонизатора 0 обработанной информации о структуре документа. Если писать его простым путем, то он будет работать в том числе в неэкранируемых строках, что крайне нежелательно. А найти эти строки без структуры документа крайне сложно, так как последовательность >> может встречаться еще и внутри комментариев и других строк.
Рассмотрим декларируемые преимущества перед YAML:
Числа в любых системах счисления. — Не уверен, что это очень востребованная возможность. Можно добавить в YAML как пользовательский тип.
Неэкранируемые строки. — Если речь про строковые блоки, то они поддерживаются в YAML. Даже синтаксис почти такой же.
Тэги. — Не очень понял, для чего они нужны. Вроде бы пользовательские типы YAML могут их заменить для юзкейсов, которые я могу представить.
Файлы. — Да, этого нет (но можно добавить как пользовательский тип на уровне парсера). Вообще, есть причина, почему это не поддерживается. Просто если добавлять такой синтаксис, то нужно добавлять абстракцию файлов (а лучше URI), делать возможность загрузки данных, а это делает парсер уязвимым, а время обработки неопределённым.
Полноценная графовая структура. — Не понял, что имеется в виду.
Легковесность. — Субъективно.
Скорость работы. — Зависит от реализации, к формату не относится.
Да, но это уже обсуждалось в другой цепочке комментариев, можете почитать.
Неэкранируемые означает, что внутри отсутвуют какие-либо спецсимволы и как следствие экранирование, то есть любой символ я могу просто записать напрямую.
Например, если вы хотите загрузить из файла объект реализующий определенный интерфейс/трейт, то в качестве тэга можно указать тип.
Файлы встроенны в формат для интеграции с якорями, крайне сложно ввести файлы отдельно от языка, что бы они могли работать вместе с якорями, обычно парсеры не дают доступа к подобной информации. Насчет безопасности - в тот же парсер на C++ встроенна точка расширения, за счет которйо можно подменить код загружающий файлы как вам нужно.
За счет якорей можно описывать полноценные графы, например можно сделать цикл из узлов ссылающихся друг на друга.
Это в минусах формата, он достаточно плохо сжимается по размеру файла.
Якоря накладывают достаточно жесткие ограничения, которые сужают круг возможных оптимизаций.
Но также в преимуществах перед YAML отсутвие Norway Problem и синтаксическая строгость.
в другой цепочке комментариев, можете почитать
Я один из участников того обсуждения. :)
В любом случае, это несложно реализуется в YAML.
Неэкранируемые означает, что внутри отсутвуют какие-либо спецсимволы и
как следствие экранирование, то есть любой символ я могу просто записать
напрямую.
В блочных скалярах YAML нет спецсимволов и экранирования.
Например,
example: |
First \n line,
"second" lineраспарсится как
{
"example": "First \\n line,\n\"second\" line\n"
}Например, если вы хотите загрузить из файла объект реализующий
определенный интерфейс/трейт, то в качестве тэга можно указать тип.
Теги есть в YAML. Их часто используют для создания кастомных типов.
Например, можно объявить свой тип !color и использовать его так:
background: !color {r: 47, g: 36, b: 66}Парсер может преобразовать цвет в какое-то внутреннее преставление и сразу выдать его.
Теги в YAML умеют намного больше, чем просто помечать узлы документа.
крайне сложно ввести файлы отдельно от языка, что бы они могли работать вместе с якорями,
Да, это так, но это решается введением специальных тегов для таких якорей и для импорта.
Честно говоря, идея глобального пространства имён для многих файлов выглядит не очень. Я бы решал задачу объединения конфигов на более высоком уровне абстракции.
Вот, например, в Kubernetes манифесты — это не один большой документ, а множество документов, описывающих ресурсы (их можно хранить в одном файле разделяя ---), которые ссылаются друг на друга по имени.
За счет якорей можно описывать полноценные графы, например можно сделать цикл из узлов ссылающихся друг на друга.
Так в любом формате это можно сделать. Разве нет? Можете пример привести?
Но также в преимуществах перед YAML отсутвие Norway Problem и синтаксическая строгость.
Norway problem решается линтером (и её нет, например, в Strict YAML).
Про синтаксическую строгость не понял. Например, JSON и YAML синтаксически строги в том смысле, что есть стандарты, описывающие их синтаксис.
В любом случае, это несложно реализуется в YAML.
Пользвоательские типы в YAML добавлются за счет строк, что делает строки двузначными.
В блочных скалярах YAML нет спецсимволов и экранирования.
Насколько мне известно YAML сам определяет уровень отступа, а следовательно в блочных скалярах в начале документа я не могу написать в начале строки более 1 пробела.
Теги есть в YAML.
Хорошо, я не полностью располагал о них информацией, поэтому в статье ? , исправлю.
Честно говоря, идея глобального пространства имён для многих файлов выглядит не очень.
У каждого файла свое пространство имен, просто они могут быть вложенны.
Так в любом формате это можно сделать. Разве нет? Можете пример привести?
&anchor key: *anchorВыйдет структура:
{
"key": {
"key": {
"key": ...
}
}
}Про синтаксическую строгость не понял.
Отсутствие свободы в использовании пробелов, табов и переносов строк например.
Насколько мне известно YAML сам определяет уровень отступа, а следовательно в блочных скалярах в начале документа я не могу написать в начале строки более 1 пробела.
Технически можете (хотя мне такое решение не нравится):
foo:
bar:
baz: |-4
Этот текст
начинается с двух пробелов.Пользвоательские типы в YAML добавлются за счет строк, что делает строки двузначными.
Не совсем понимаю при чём тут строки, можете пояснить?
Если говорить про скалярные пользовательские типы, то добавляются они за счет тега + строки.
Да нет, строка не нужна. Вот я выше пример с типом color привёл.
Он нескалярный
Так и для скаляров не нужно. Например, можно единицы измерения указывать:
distance: !km 15Я даже проверил на всякий случай, что это парсится.
В парсере когда встречается тег, обработчик тега получает узел дерева разбора, а дальше он сам уже может делать всё, что захочет. Скаляр это или нет значения не имеет.
Самый непонятный выбор для меня это yes/no в качестве true/false из-за ЦА, потому что по остальным фичам формат явно не только для обывателей.
А так как я не являюсь экспертом в различных форматах, то не хватило в статье прямых сравнений с другими форматами. Например, почему строки у вас реализованы именно так, чем варианты TOML или YAML хуже.
Есть 14 языков для хранения данных… Или как появился IEML