Хах) не, такого не держим)

Ту тогда прямой путь к нему в вопрсом как быть ? или фиче реквайст возможно что он не знал раньше что это может потребоваться в таком виде

go:linkname

не то?

Ту тогда прямой путь к нему в вопрсом как быть ? или фиче реквайст возможно что он не знал раньше что это может потребоваться в таком виде

Ну если б он был доступен, я бы к вам не пришел)

про рефлексию я наврал, похоже, что-то не так усвоилось

http://www.alangpierce.com/blog/2016/03/17/adventures-in-go-accessing-unexported-functions/

мб с типами тоже прокатит

Ну если б он был доступен, я бы к вам не пришел)

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

Товарищи, а го гарантирует выполнения выражений слева на право? Т.е. я правильно понимаю что такой код инкогда не запаникует? if err !=nil && err.Error() == “some error” { } Поскольку проверка на нил всегда будет раньше вызова .Error

а что вы скажите по поводу viper+cobra?

что-то тут советуют вместо велосипеда

но как то и с ним неплохо жилось

Товарищи, а го гарантирует выполнения выражений слева на право? Т.е. я правильно понимаю что такой код инкогда не запаникует? if err !=nil && err.Error() == “some error” { } Поскольку проверка на нил всегда будет раньше вызова .Error

гарантирует

что-то тут советуют вместо велосипеда

какого велосипеда?

Товарищи, а го гарантирует выполнения выражений слева на право? Т.е. я правильно понимаю что такой код инкогда не запаникует? if err !=nil && err.Error() == “some error” { } Поскольку проверка на нил всегда будет раньше вызова .Error

Только ошибку на наличие определенного текста лучше не проверять.

Только ошибку на наличие определенного текста лучше не проверять.

Это да, просто хотелось привести простой пример

какого велосипеда?

ну обычная структура + unmarshal из json/yaml + flags стандартный

обычно ничего больше и не надо

ну я про https://github.com/spf13/viper

я вообще стараюсь флагами обходиться, файл всплывает тольк если мне пароль к базе надо где-то хранить

я знаю, про что

и вот еще https://github.com/spf13/cobra

ну хз я тоже так думаю

нафиг сторонние либы

хотя в принципе что-то орали там про "промышленный стандарт"

хотя вроде у нас стандарт не использовать либы O_o

не

вайпер - это стандарт

про кобру не помню

просто оно обычно не надо совсем

мне просто не совсем понятно

нафига, когда можно в структуру накормить и провалидировать там же

декларативный стиль

Кто-то запиливал логгирование запросов как в горме для sqlx? Чтобы логгировало сам запрос + время выполнения + rows affected.

ты описываешь параметры исчерпывающе, робот делает остальное

ты описываешь параметры исчерпывающе, робот делает остальное

как всегда сломаемся на кастом каком либо

нас еще прокруст учил, как с этим быть

я этот момент не застал ?

описан в специальной литературе подробно

*прокрустово ложе (Кун, Легенды и мифы Древней Греции)

ну я же говорю, я не настолько стар ?

я правильно понимаю что $GOPATH/src/project/internal/shared будет доступно только в пределах $GOPATH/src/project и не экспортируется наружу?

я правильно понимаю что $GOPATH/src/project/internal/shared будет доступно только в пределах $GOPATH/src/project и не экспортируется наружу?

Что значит "не экспортируется наружу"

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

Что значит "не экспортируется наружу"

в API пакета project

я правильно понимаю что $GOPATH/src/project/internal/shared будет доступно только в пределах $GOPATH/src/project и не экспортируется наружу?

неправильно

для начала, конструкция $GOPATH/src/project/internal/shared не имеет права на существование, в GOPATH можетыть несколько путей

в API пакета project

В го нет сокрытия\видимости пакетов, потому все из $GOPATH доступно везде

В го нет сокрытия\видимости пакетов, потому все из $GOPATH доступно везде

если оно с Большой буквы начинается:)

если оно с Большой буквы начинается:)

Пакетов, а не типов в пакетах

ну это смотря что иметь в виду под "всё". Пакеты, типы или вообще всё.

вот у меня есть файл https://github.com/qbeon/webwire-go/blob/master/client/socketImpl.go в /webwire-go/client/ его-же копия https://github.com/qbeon/webwire-go/blob/master/socketImpl.go в /webwire-go/ т.е. client использует подобную имплементацию сокета, но не может её использовать из корневого пакета поскольку эти функции/типы не экспортируются

экспортировать объекты socketImpl.go нельзя наружу, поэтому я тогда побыстрому просто скопипастнул из корневого в client

но это естественно нехорошо, DRY всё-таки

ну - такова селяви

вообще-то, если одно и тоже используется в разных пакетах - его надо оформлять либой, в своем репо

IMHO

ну это уж слишком в данной ситуации))

нет никакой другой альтернативы?

можно конечно оставить и копию, ибо там критичного кода нет и меняться он не будет

ну это уж слишком в данной ситуации))

самое правильное - отдельный пакет

самое правильное - отдельный пакет

как отдельный суб-проект?

нет отдельная репа

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

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

в даннон случае не сработает, ибо субпакет должен в таком случае экспортировать всё, что непозволимо ибо там gorilla/websocket в API

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

ERROR: S client not available

стоит пересмотреть архитектуру

что бы он оборачивал без торчащих ног

стоит пересмотреть архитектуру

дак как?)) есть /client и есть корневой пакет, клиент представляет собой под-проект который переместить в другую репу я не могу, он используется в тестах

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

плюс его тесты

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

его это кого?) имплементацию клиента? они так и делают

я не совсем врубаюсь

у вас есть socketImpl, что мешает его переместить в пакет отдельно?

вот конкретно

у вас есть socketImpl, что мешает его переместить в пакет отдельно?

то что придётся экспортировать его API, что непозволимо. Это имплементация абстрактного интерфейса сокета на основе gorilla/websocket gorilla/websocket однако не должен экспортироваться в API webwire по причине описанной в этом issue: https://github.com/qbeon/webwire-go/issues/2

я думал если запихать его в webwire-go/internal/socket тогда он не экспортируется в API webwire, но видимо это не так

это не так

Ну если б он был доступен, я бы к вам не пришел)

https://github.com/alangpierce/go-forceexport если есть неэкспортированный конструктор для private в пакете

https://github.com/alangpierce/go-forceexport если есть неэкспортированный конструктор для private в пакете

Спасибо)

через рефлект?

АСТОНОВИТЕСЬ

то что придётся экспортировать его API, что непозволимо. Это имплементация абстрактного интерфейса сокета на основе gorilla/websocket gorilla/websocket однако не должен экспортироваться в API webwire по причине описанной в этом issue: https://github.com/qbeon/webwire-go/issues/2

какая религия говорит вам это "то что придётся экспортировать его API, что непозволимо"

какая религия говорит вам это "то что придётся экспортировать его API, что непозволимо"

не религия, а тот факт, что в таком случае внешне появится лишняя зависимость gorilla/webwire, которая сейчас скрыта в недрах библиотеки

ээм

с чего вы взяли?

с чего вы взяли?

что именно?)

у вас же есть структура socket которая шариться через фабрику

вернее у вас newConnUpgrader основная фабрика насколько понимаю

у вас же есть структура socket которая шариться через фабрику

интерфейс, не структура

https://github.com/qbeon/webwire-go/blob/master/socket.go

ээм

у нас же утиная типизация

у нас же утиная типизация

ну да, и что?)

еще раз, вы из внешки вызываете - NewConnUpgrader

он иницилизирует connUpgrader

из внешки при этом не будет требоваться же импорт - github.com/gorilla/websocket

еще раз, вы из внешки вызываете - NewConnUpgrader

из внешки?