Почему не ТОМЛ?
# это некий TOML
name = 'TOML'
[created-by]
name = 'Tom Preston-Werner'
dob = 1979-05-27T07:32:00-08:00
TOML - это формат файла конфигурации, разработанный как «улучшенный» INI-файл.
Сначала TOML выглядит как простой, читаемый формат файла. Если вы используете его нечасто для небольших простых файлов, ничего страшного.
Но чем больше вы его используете, тем больше вы заметите недостатки TOML.
Мартин Вейнар, создатель PyTOML, сказал то же самое. Первоначально он построил парсер TOML из энтузиазма, но в конце концов отказался от него:
TOML - плохой формат файла. На первый взгляд это выглядит хорошо, и для действительно очень тривиальных вещей это, вероятно, хорошо. Но как только я начал его использовать и схема конфигурации стала более сложной, я нашел синтаксис некрасивым и трудным для чтения.
Итак, в чем проблема с TOML?
1. Слишком подробный
Это документ на yaml:
json:
- rigid
- better for data interchange
yaml:
- slim and flexible
- better for configuration
object:
key: value
array:
- null_value:
- boolean: true
- integer: 1
- alias: &example aliases are like variables
- alias: *example
paragraph: >
Blank lines denote
paragraph breaks
alias: &foo
bar: baz
alias_reuse: *foo
И вот то же самое в TOML:
json = [
"rigid",
"better for data interchange"
]
yaml = [
"slim and flexible",
"better for configuration"
]
paragraph = """
Blank lines denote
paragraph breaks
"""
[object]
key = "value"
[[object.array]]
[[object.array]]
boolean = true
[[object.array]]
integer = 1
[[object.array]]
alias = "aliases are like variables"
[[object.array]]
alias = "aliases are like variables"
[alias]
bar = "baz"
[alias_reuse]
bar = "baz"
Первые примеры YAML - 368 символов. Второй - 455 знаков. Это еще примерно 100 символов, которые вам нужно ввести. TOML заново представляет то, от чего дружественные к человеку языки пытаются избавиться: подробный синтаксис, необходимость заключать строки в кавычки и многое другое.
Причины очевидны:
- Когда у вас есть массив, вам нужно повторять ключ снова и снова (
[[object.array]]
) - В TOML преобладает множество синтаксических дополнений, таких как квадратные скобки и кавычки.
- Нет системы псевдонимов.
Уменьшение размера программ и использование DRYer значительно сокращает количество ошибок. То же самое можно сказать и о файлах конфигурации.
2. Похоже, что TOML был разработан для парсеров.
Иерархия в TOML определяется символом .
. Это достаточно просто для понимания парсеров, но это усложняет нам задачу.
Вот почему многие люди приняли этот стиль:
[markup]
[markup.tableOfContents]
endLevel = 8
startLevel = 1
[markup.highlight]
style = "solarized-dark"
Хотя это упрощает понимание, было бы намного лучше, если бы мы могли избавиться от точек (и скобок) и просто использовать только отступ. Вот почему мне нравится синтаксис Python.
До сих пор ведутся споры о том, было ли использование одного отступа хорошей идеей, но, как правило, это так, как обсуждается в этом вопросе StackExchange.
3. В TOML слишком много функций.
Создатель TOML критикует YAML за то, что у него слишком много функций, а затем делает то же самое. Иронично.
Например, у TOML есть даты первого класса. Если вы программировали какое-то время, вы знаете проблемы, связанные с датой и временем.
На мой взгляд, типов должно быть всего 5: строка, число, логическое значение, массив, объект. Это подход, принятый JSON, и это хорошее решение.
4. Типизация синтаксиса
Взгляните на это:
str = "string"
num = 42
TOML позволяет пользователям решать, что это за тип. Но в большинстве случаев это неверно, так как клиент должен решить, какой тип должна быть у вещи. Если типы неверны, они должны быть принудительно изменены или должна быть выдана ошибка.
4. Не очевидные правила TOML
Большая часть TOML очевидна, но не все.
Например [[syntax]]
, сбивает с толку. Он выглядит как [object]
с дополнительной парой []
вокруг него, но используется для обозначения массива.
Если вы думаете, что я упустил какие-то пункты, или если вы не согласны с какими-либо пунктами, которые я высказал, пожалуйста, оставьте комментарий!