Comments 9
есть ограничения, делающие эту возможность бесполезной для нас,
Эти теги — один из примеров ущербности языка Go. Конечно, кое-какие проблемы вы исправили, но у них есть фундаментальные недостатки
type Article struct {
Text string `json:"text,omitempty,string" xml:"foo"`
}
Во-первых, просто отвратный синтаксис, который заставляет писать все теги и их свойства в одну строку. WAT? Автор, ты это сделал специально, чтобы ими было неудобно пользоваться? Но, допустим, это вкусовщина.
Значительно больнее — во-вторых: они динамичны. WAT? Это go или php? Та даже декораторы в JS и то адекватнее! Никакой проверки ошибок в компайл-тайме. Более того, ее даже толком в ide и рантайме нету (как в JS). Я могу написать «omit-empty» вместо «omitempty» и оно просто будет неправильно сериализовать JSON. WAT? Как результат — никакой документации в IDE. Хочешь узнать, какие теги можешь использовать — лезь в документацию. WAT? Какие опции? В документацию! WAT?
В дополнение я просто процитирую статью:
* структурный тег — это строковый литерал
* Настройка опций не описана в определении
То есть каждая либа придумывает такой формат, какой ей удобен.
Автор может и исправил пару недостатков тегов, но не исправил их фундаментальный недостаток. Какой тег использует либа — указано где-то в середине ее функции на 1110 строке огромного файла посреди кучи говнокода.
Автор языка, за что ты так ненавидишь программистов на Go?
Неужели нельзя было сделать как-нибудь статически-типизированно?
type Article struct {
@xml.Tag{ key:"foo" }
@json.Tag{ key:"text", omitempty: true, string: true }
Text string
}
Или, если хотелось бы уйти от ужасного C# и написать в стиле богоподобного Go в одну длинную строчечку:
type Article struct {
Text string [2]struct{ xml.Tag{ key:"foo" }, json.Tag{ key:"text", omitempty: true, string: true } }
}
Автор языка, за что ты так ненавидишь программистов на Go?
Неужели нельзя было сделать как-нибудь статически-типизированно?
Страдай ^_^
Не так уж сильно оно и усложняет компилятор при правильном дизайне.
В D можно писать так:
struct xml_tag { string name }
struct json_field { string key }
struct omit_empty {}
struct Article
{
@ xml_tag( "foo" )
@ json_field( "text" )
@ omit_empty()
string text
}
Соответственно к полю можно прицепить любые типы значений, а потом в библиотеке получить их список и обработать.
Мне теги нравятся в том виде в котором есть, структура получается лаконичной, легко читать и понимать что происходит.
Сложно представить использование этой утилиты в реальном проекте.
Казалось бы — охота упростить, но нет — предлагают заюзать и разобраться как работает еще одна тулза… А в результате этих генераций всеравно чуть ли не каждой переменной в структуре необходимо внимание.
А если переводим на Go некоторый апи-сервис, который среди реквестов-респонсов имеет поля: id, userid, purshare_id, createdAt и т.п. (не важно почему, вот так вот есть и менять нельзя — много клиентов такое отправляют и в ответе ожидают, плюс добавить несогласованность полей БД и ясон в рекв./респ.) — автоматизирование тегов превратилось бы в ад.
Вообще теги делают структуры удобным инструментов, создаешь одну структуру для сущности, описываешь в тегах ее поведение, и используешь для request-response-database.
Не понимаю чего так пристали к этим тегам, не в одном месте вижу движения «чтото с ними сделать».
А ведь GO обещал быть простым и понятным языком.
Оказалось простота рушиться когда устаешь писать одно и тоже, и хочется абстракций помощнее.)
На мой взгляд его бедный синтаксис преподносился как одно из преимуществ, утверждалось что это позволит чуть ли не любому новичку в кратчайшие строки влиться в проект, потому как код будет прост и понятен. По этому я и написал что видели.)
Но соглашусь, для меня так же было сразу очевидно что писать бизнес логику на этом языке будет очень напряженно, придется писать много шаблонного кода и как результат в каждом проекте появятся свои абстракции, по факту — костыли.
Полное руководство по написанию утилиты для Go