Полное руководство по написанию утилиты для Go

[TheShock]

есть ограничения, делающие эту возможность бесполезной для нас,

Эти теги — один из примеров ущербности языка 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 } }
}

[humbug]

Автор языка, за что ты так ненавидишь программистов на Go?
Неужели нельзя было сделать как-нибудь статически-типизированно?

Страдай ^_^

[SirEdvin]

Думаю, ответ в Go на все один: «Это усложняет компилятор».

[vintage]

Не так уж сильно оно и усложняет компилятор при правильном дизайне.

В 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
}

Соответственно к полю можно прицепить любые типы значений, а потом в библиотеке получить их список и обработать.

[SirEdvin]

Это уже больше к авторам Go, на самом деле. Они считают, что усложняет, не мне их судить, как бы.

[KirEv]

Статья понравилась, спасибо за перевод, но лишь как демонстрация и анализ из серии «как можно сделать», собственно оглавление на это намекает: «The ultimate guide to writing a Go tool»

Мне теги нравятся в том виде в котором есть, структура получается лаконичной, легко читать и понимать что происходит.

Сложно представить использование этой утилиты в реальном проекте.

Казалось бы — охота упростить, но нет — предлагают заюзать и разобраться как работает еще одна тулза… А в результате этих генераций всеравно чуть ли не каждой переменной в структуре необходимо внимание.

А если переводим на Go некоторый апи-сервис, который среди реквестов-респонсов имеет поля: id, userid, purshare_id, createdAt и т.п. (не важно почему, вот так вот есть и менять нельзя — много клиентов такое отправляют и в ответе ожидают, плюс добавить несогласованность полей БД и ясон в рекв./респ.) — автоматизирование тегов превратилось бы в ад.

Вообще теги делают структуры удобным инструментов, создаешь одну структуру для сущности, описываешь в тегах ее поведение, и используешь для request-response-database.

Не понимаю чего так пристали к этим тегам, не в одном месте вижу движения «чтото с ними сделать».

[AlexTheLost]

А ведь GO обещал быть простым и понятным языком.
Оказалось простота рушиться когда устаешь писать одно и тоже, и хочется абстракций помощнее.)

[mayorovp]

«Оказалось»? Это же с самого начала было понятно.

[AlexTheLost]

На мой взгляд его бедный синтаксис преподносился как одно из преимуществ, утверждалось что это позволит чуть ли не любому новичку в кратчайшие строки влиться в проект, потому как код будет прост и понятен. По этому я и написал что видели.)
Но соглашусь, для меня так же было сразу очевидно что писать бизнес логику на этом языке будет очень напряженно, придется писать много шаблонного кода и как результат в каждом проекте появятся свои абстракции, по факту — костыли.