Есть у меня спецификация OpenAPI, описанная, как полагается, в YAML-файле. Из этой спеки генерируется бойлерплейт для сервера на Echo (об этом как-нибудь отдельно могу рассказать). Так вот, запускаю я после очередного обновления спеки кодогенерацию и получаю ошибку. Мол, не могу распарсить в поле
required значение как bool, так как никакого bool здесь быть не должно. Место, на которое ругался кодогенератор выглядит так:points:
type: array
required: [ id, x, y ]
items:
type: object
properties:
id:
type: string
x:
type: number
y:
type: numberПодумайте, где здесь может прятаться булеан? У меня не заняло много времени его обнаружить, но когда это произошло, я резко захотел в отпуск. В YAML 1.1 символ
y интерпретируется как true. Более того, y и n являются каноничными записями для булевых значений (а не true и false, казалось бы). Полный регексп для булеана выглядит так:y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFFУ меня в связи с этим есть вопрос (риторический, конечно же):
Кто решил, что такой синтаксис для булеанов — это отличная идея, и обычных
true с false не будет достаточно? Неужели ни у кого из авторов формата не возникло мысли, что такие ключевые слова языка обязательно пересекутся с названиями полей?В какой-то момент авторы видимо поняли, что
y и n и прочие “human-friendly” варианты для булеанов (иронично вышло) — это слишком гениально, и в YAML 1.2 уже оставили только true и false. Казалось бы, круто, решили проблему, двигаемся дальше. Но в итоге половина библиотек и инструментов поддерживает старый синтаксис, а половина — нет. Поэтому теперь сходу нельзя быть уверенным в том, как будет интерпретироваться y — как строка или как булеан. Для однозначной интерпретации теперь приходится писать "y" (я не шучу).Снова кто-то попытался сделать язык для машин языком для людей и наломал дров. От принятого изначально решения читаемость формата наоборот стала хуже, потому что
y — не всегда просто y.