как в таком случае описать const [] const *Object ?

Не знаю :)

как в таком случае описать const [] const *Object ?

const [] *Object

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

но!

с моей точки зрения const модификатор не типа, но экземпляра

Ну, вобще-то да. Уж если мы говорим что контейнер не меняется, то это как раз по поводу содержимого и речь

И вобще, даже при косвенном доступе (любых степеней вложенности) объект, объявленный как конст, или его часть. не может по идее быть lvalue

это тут уже было сегодня дважды

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

да, в этом есть смысл. если учесть что slice это всего лишь type slice struct { p *[n]array } тогда поля const object'а должны быть тоже const type Object struct { Parent *Object } func main() { const o := &Object{} o.Parent = &Object{} // Compile-time error o.NonConstMethod() // Compile-time error o.Parent.NonConstMethod() // Compile-time error } в чём, собственно, есть смысл.

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

однако, что если нам нужен мутабельный слайс немутабельных объектов?

в го же планируют вводить check/handle паттерны?

однако, что если нам нужен мутабельный слайс немутабельных объектов?

с моей точки зрения const модификатор не типа, но экземпляра

чего вы так упарываетесь по "аа мы всё сломаем, нельзя новые кейворды"? чек/хендл сломает в 100500 раз больше, чем какой-нибудь mut :)

чек-хендл придумал кокс, и у него серьезные шансы попасть в язык

а const придумал Роман (не целиком, но этот конкретный пропозал), и у него шансов мало, разве что он всем вот прям понравится-понравится

Ясно :)

я вот все же думаю, что начинать надо с комментов-аннотаций, и линтера

чего вы так упарываетесь по "аа мы всё сломаем, нельзя новые кейворды"? чек/хендл сломает в 100500 раз больше, чем какой-нибудь mut :)

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

а const придумал Роман (не целиком, но этот конкретный пропозал), и у него шансов мало, разве что он всем вот прям понравится-понравится

да уж)) const скорее придумал Stroustrup (или откуда он там взялся) в C++, я лишь пытаюсь грамотно перевести его в Go

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

Ну о том тут и речь уже 2..3 дня, "нельзя новые кейворды для беквард компат."

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

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

С чек/хендл хендл может быть только проблема у тех буратин, кто ошибку возвращал не последним значением

С чек/хендл хендл может быть только проблема у тех буратин, кто ошибку возвращал не последним значением

Нет, причем тут вообще ошибка

Я могу запросто переменную/функцию сейчас и чек, и хендл назвать

И оно сломается

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

И оно сломается

Можно решить явным импортом в начале файла (например)

я вот все же думаю, что начинать надо с комментов-аннотаций, и линтера

да, в этом есть смысл. Можно с этого начать, правда я Go линтеры ещё не писал, сложно оценить насколько это будет сложно и затратно по времени. можно добавить эту идею в пропосал как PoC implementation, осталось только придумать стандарт/формат аннотаций, есть по этому поводу идеи?

есть

к переменным и типам - теги

к переменным и типам - теги

а если чуть более конкретно?

к параметрам - комменты того же формата, что и теги

завтра конкретно :)

завтра конкретно :)

??

таааак

а почему мы, собственно, так хотим ключевое слово?

у нас же есть возможность алиасить типы!

а почему мы, собственно, так хотим ключевое слово?

ты про что конкретно сейчас?

type intConst int // immutable

и все, пользуйся на здоровье, пиши линтер

может быть даже type intConst = int // immutable

type intConst int // immutable

аа, вон оно чё.. интересное предложение. Надо подумать

Линтер это клёво но он же вас оставит без возможности оптимизаций компилятора

а мы для начала

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

Давайте сразу ещё null safety тогда

я не понимаю, при чем тут null safety

Линтер это клёво но он же вас оставит без возможности оптимизаций компилятора

линтер это PoC - Proof of Concept

я не понимаю, при чем тут null safety

так же вполне возможно реализовать на уровне линтера и с помощью алиасов

а как? я всегда думал, что это runtime проблема

а как? я всегда думал, что это runtime проблема

Неа В том же kotlin это реализовано на этапе компиляции

есть подозрение, что у нас все же другой язык :) в котлине негде взять null, кроме как явно его присвоить

у нас - масса вариантов

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

есть подозрение, что у нас все же другой язык :) в котлине негде взять null, кроме как явно его присвоить

у нас можно трассировать наличие nil из "корней", типа var, init и main функции из стандартной библиотеки можно и нужно аннотировать отдельно ничего невозможного в принципе нет

Коллеги. В общем насоздовал несколько интерфейсов по 1-2 метода каждый. Имплементировал их нужным структурам. Есть метод, возвращающий один из этих интерфейсов. На выходе мне надо сделать действие, пренадлежащее другому интерфейсу. Не зашкварно ли так делать? s.(OtherInterface).OtherInterfaceMethod()

for range перестанет выполняться?

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

v, ok := <-yourChan if !ok { //chan closed }

понял

Коллеги. В общем насоздовал несколько интерфейсов по 1-2 метода каждый. Имплементировал их нужным структурам. Есть метод, возвращающий один из этих интерфейсов. На выходе мне надо сделать действие, пренадлежащее другому интерфейсу. Не зашкварно ли так делать? s.(OtherInterface).OtherInterfaceMethod()

И в таком ключе оперировать со структурами, имплементирующими эти интерфейсы

for range перестанет выполняться?

перестанет и выйдет из цикла

у нас можно трассировать наличие nil из "корней", типа var, init и main функции из стандартной библиотеки можно и нужно аннотировать отдельно ничего невозможного в принципе нет

вероятность ниже 100% существенно

ERROR: S client not available

перестанет и выйдет из цикла

понял

не уверен, что кто-=то захочет на это тратить время

Коллеги. В общем насоздовал несколько интерфейсов по 1-2 метода каждый. Имплементировал их нужным структурам. Есть метод, возвращающий один из этих интерфейсов. На выходе мне надо сделать действие, пренадлежащее другому интерфейсу. Не зашкварно ли так делать? s.(OtherInterface).OtherInterfaceMethod()

используй композицию интерфейсов https://play.golang.org/p/tAJxyIs0rxi

используй композицию интерфейсов https://play.golang.org/p/tAJxyIs0rxi

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

не уверен, что кто-=то захочет на это тратить время

meh это как с любыми другими линтерами нужно быть достаточно сумашедшим чтобы такое поддерживать

используй композицию интерфейсов https://play.golang.org/p/tAJxyIs0rxi

А мой вариант плох с точки зрения культуры кода?

Про производительность речи не веду

А мой вариант плох с точки зрения культуры кода?

паникой в случае если прошляпил типы

паникой в случае если прошляпил типы

Это сугубо на свою совесть оставляю, согласен

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

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

1 канал и воркеры которые из него берут себе работу

огонь, так даже лучше

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

https://geeks.uniplaces.com/building-a-worker-pool-in-golang-1e6c0fdfd78c

https://groups.google.com/forum/m/#!topic/golang-codereviews/qJHZTBYyRuQ

https://youtu.be/1B71SL6Y0kA

Всем салют!Вопрос таковой 1.Как выполнить аутентификацию админа?так чтобы посторонних перенаправлял в корневой URL роуты: "/v1/admin/login" "/v1/admin/application "/v1/"

Всем салют!Вопрос таковой 1.Как выполнить аутентификацию админа?так чтобы посторонних перенаправлял в корневой URL роуты: "/v1/admin/login" "/v1/admin/application "/v1/"

Go-jwt

Всем салют!Вопрос таковой 1.Как выполнить аутентификацию админа?так чтобы посторонних перенаправлял в корневой URL роуты: "/v1/admin/login" "/v1/admin/application "/v1/"

миддлвер

проблем с доступностью не будет?

названия видимо придумывала секретарша

Я вот не понял вопрос

почему в Go принято писать названия значений в структурах с большой буквы? Это чисто стилистика или есть причины?

почему в Go принято писать названия значений в структурах с большой буквы? Это чисто стилистика или есть причины?

С большой буквы - public

С маленькой - private

почему в Go принято писать названия значений в структурах с большой буквы? Это чисто стилистика или есть причины?

С большой буквы доступны во всех пакетах а маленькие только внутри

почему в Go принято писать названия значений в структурах с большой буквы? Это чисто стилистика или есть причины?

Го тур то прошли?

да, уже третий пет.проект на го собираю, json с клинтом по ws гоняю и думаю нагенерить структуры с TypeScript получается удобней описать структуры например в yaml и нагенерить уже интерфейсы и структуры для go/ts

Всем привет!