А почему может не работать ldflags? Делаю в пакете system переменную var Branch string, собираю через go build -ldflags "-X system.Branch=master" и при запуске в переменной пустая строка все равно.

если я правильно помню, нужно указывать полный путь к package

И правда, так работает.

что-то попробывал с DI

ну "такое"

как мокать такие хедлеры не понятно

придется мокать весь "супер обьект"

придется мокать весь "супер обьект"

в чем проблема?

покажи свой хэндлер

type UsersHandler struct { app *application.MyApplication } func (h * UsersHandler) Index(w http.ResponseWriter, r *http.Request, p httprouter.Params) { ... h.app.GetResponce().EmptySuccess(w) }

ну что-то в этом стиле

самый минимальный показал

ну и конструктор конечно: func NewClinicHandler(app *application.MyApplication) *UsersHandler { return &UsersHandler{ app: app, } }

хэндлер у тебя зависит от приложения? странно

обычно он зависит например от db-слоя, сервисов

у меня есть пакет application

в нем в фабрике - NewApplication стартуют все подключения, все что при инициализации делается

так является ли application зависимостью для хэндлера?

они свои "коннекты" кидают в стуктуру и эта структура уже начинает везде фигурировать

так является ли application зависимостью для хэндлера?

она прозрачно прокидывает во все связи

на самом деле там есть абстракция webserver, потом уже от нее идет прокидывания в хедлер того же самого

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

это такое аналог DI

ок. я отвечу за тебя. не является. прокидывать dic - это известный антипаттерн. если ты прокидываешь dic, то у тебя не di, а его имитация. Потому и протестить не сможешь нормально

а что есть dic?

di container

контейнер твоих зависимостей

так

а как тогда правильно? если мы хотим таки DI

прокидывать не dic, а конкретные зависимости

а зачем нам тогда DI?

а зачем нам тогда DI?

в вики прочти)

да читал

я думал что в этом и заключается

что мы контейнер лихо пихаем везде и забывает про зависимости

ок. я отвечу за тебя. не является. прокидывать dic - это известный антипаттерн. если ты прокидываешь dic, то у тебя не di, а его имитация. Потому и протестить не сможешь нормально

Не понял позицию, то есть делать руками DI это хорошо (оно и понятно), а взять fx от uber уже плохо?

Не понял позицию, то есть делать руками DI это хорошо (оно и понятно), а взять fx от uber уже плохо?

нет, это вообще не про то речь

нет, это вообще не про то речь

может быть вы имеете введу что в DI должен "рефлектом" смотреть за зависимостями и подцеплять их?

а хедлеры в тестах значит работают без DI и кормяться вручную

может быть вы имеете введу что в DI должен "рефлектом" смотреть за зависимостями и подцеплять их?

нет

уже есть какие-нибудь фреймворки кодогенераторы декларативных API тестов?

ну я просто знаю как в PHP сделан DI, все классы которым требуются зависимости дергаются через оберточку аля DI("/namespace/className") дальше уже движок разбирает что там в конструкторе за зависимости и пытается их накормить (если есть)

есть идея как реализовать декларативные тесты GraphQL апишек, определяешь: 1. query 2. ожидаемый JSON 3. conditions (макро-функции, реализуются в Go коде)

Коллеги, панику из горутины никак не отловить?

Коллеги, панику из горутины никак не отловить?

defer func() { f := recover() }()

https://play.golang.org/p/N6NGMFH86g2

https://play.golang.org/p/N6NGMFH86g2

не выйдет, вы стартуете новый поток

в нем и отлавливайте

Т е автоматически никак.

Т е автоматически никак.

https://play.golang.org/p/07uP2U2Z1Kd

ну я просто знаю как в PHP сделан DI, все классы которым требуются зависимости дергаются через оберточку аля DI("/namespace/className") дальше уже движок разбирает что там в конструкторе за зависимости и пытается их накормить (если есть)

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

ну окей

в гоу то как принято с DI?

в го не принято di, сам знаешь

https://play.golang.org/p/07uP2U2Z1Kd

Это означает что в контексте горутины нужно отлавливать и по другому никак?

Это означает что в контексте горутины нужно отлавливать и по другому никак?

только так

Ок, спасибо

в го не принято di, сам знаешь

когда я описывал свою с вашего позволения "архитектуру" никто даже не пикнул 🙁

наоборот все говорили "ну зависимости надо статически отдавать и ок"

в смысле методов наделать аля GetDB()

когда я описывал свою с вашего позволения "архитектуру" никто даже не пикнул 🙁

у тебя память плохая)

в смысле методов наделать аля GetDB()

а в чем проблема? GetDb норм

и где его простите применять?

если я не могу контейнер с ним скоримть в хедлер

и где его простите применять?

если это метод контейнера

в данном случаи этот контейнер в структуре MyApplication

postStore := NewPostStore(container.GetDb()) userStore := NewUserStore(container.GetDb())

и зачем это?

я с такми же успехом могу написать

а не postStore := NewPostStore(container) userStore := NewUserStore(container)

db := db.NewConnect() ostStore := NewPostStore(db) userStore := NewUserStore(db)

почему тогда сразу не так?

только сущность наплодили "лишную"

и зачем это?

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

db := db.NewConnect() ostStore := NewPostStore(db) userStore := NewUserStore(db)

можно так. ты же просто переименовал метод

нихрена

если он не создает новый коннект кажддый раз, то это норм

создает

ну а зачем?

мы же в main и это уже вызов идет бд непосрдественно

так что сказать то хочешь?