встроено

Помогите. Как понять, вот создаю я хандлеры, или делаю через Mux допустим, затем http.ListenAndServe и оно однопоточное? Всмысле, при запросе нескольких клиентов где мне надо разваливаться на отдельные потоки (или не надо и оно уже встроено?)

на каждый реквест создается горутина

автоматически

Кайф. Спасибо вам.

в таком случае интерфейс определяет, что опредлённые методы не должны мутировать объект имплементирующий этот интефейс, хорошо ли это? должен ли интерфейс иметь право запрещать мутации на определённых методах?

Помогите. Как понять, вот создаю я хандлеры, или делаю через Mux допустим, затем http.ListenAndServe и оно однопоточное? Всмысле, при запросе нескольких клиентов где мне надо разваливаться на отдельные потоки (или не надо и оно уже встроено?)

Го настолько прост, что на многие вопросы ты можешь ответить сам и прояснить, здесь видно, как принимается соединение и обработка в горутине) https://golang.org/src/net/http/server.go#L2805

в таком случае интерфейс определяет, что опредлённые методы не должны мутировать объект имплементирующий этот интефейс, хорошо ли это? должен ли интерфейс иметь право запрещать мутации на определённых методах?

вот надо подумать

скорее нет, чем да

вот надо подумать

я пока что не вижу проблем. Но может есть таки кейсы в которых это бы было недопустипо? В таких ситуациях без помощи зала… вернее community не обойтись

так как всё равно нет запрета на мутацию вложенных по указателю данных, как я понял

то есть имеет ли смысл выносить такие тонкие вопросы в язык?

Обнаружил в горилле вебсокетах такое - вместо timeout автор оперирует понятием deadline и ждет time.Now()+таймаут, потом вычитает из него time.Now(), кто знает, зачем это было сделано? https://github.com/gorilla/websocket/blob/master/conn.go#L393

так как всё равно нет запрета на мутацию вложенных по указателю данных, как я понял

запрета на мутацию вложенных по указателю данных? ты о чём?

Обнаружил в горилле вебсокетах такое - вместо timeout автор оперирует понятием deadline и ждет time.Now()+таймаут, потом вычитает из него time.Now(), кто знает, зачем это было сделано? https://github.com/gorilla/websocket/blob/master/conn.go#L393

https://github.com/gorilla/websocket/issues/52

так как всё равно нет запрета на мутацию вложенных по указателю данных, как я понял

без такого запрета вся затея теряет смысл

запрета на мутацию вложенных по указателю данных? ты о чём?

ну вот структура, в ней указатель на другую структуру, метод не меняет саму исходную структуру, но меняет структуру по указателю (сам указатель не меняется при этом)

https://github.com/gorilla/websocket/issues/52

Интересно, спасибо, я уже хотел было PR повесить)

https://github.com/golang/go/issues/27443

Обнаружил в горилле вебсокетах такое - вместо timeout автор оперирует понятием deadline и ждет time.Now()+таймаут, потом вычитает из него time.Now(), кто знает, зачем это было сделано? https://github.com/gorilla/websocket/blob/master/conn.go#L393

так в стандартной библиотеке сделано - там тоже не таймаут, а дедлайн. позволяет не хранить внутри "время последней операции"

так в стандартной библиотеке сделано - там тоже не таймаут, а дедлайн. позволяет не хранить внутри "время последней операции"

Тогда неконсистентно, здесь уже таймаут, например, в клиенте https://github.com/gorilla/websocket/blob/master/client.go#L71

Тогда неконсистентно, здесь уже таймаут, например, в клиенте https://github.com/gorilla/websocket/blob/master/client.go#L71

я не ответственнен за это

Все в го так говорят

смысла нет со мной это обсуждать, тем не менее

ну вот структура, в ней указатель на другую структуру, метод не меняет саму исходную структуру, но меняет структуру по указателю (сам указатель не меняется при этом)

type Object struct { parent *Object } func (o *Object) SetParent(newParent *Object) { return o.parent = newParent // Mutation } func (o const *Object) ReadOnlyMethod() { // You can’t call a function with a non-const receiver // on an immutable receiver „o“ o.parent.SetParent(&Object{}) // Compile-time error }

type Object struct { parent *Object } func (o *Object) SetParent(newParent *Object) { return o.parent = newParent // Mutation } func (o const *Object) ReadOnlyMethod() { // You can’t call a function with a non-const receiver // on an immutable receiver „o“ o.parent.SetParent(&Object{}) // Compile-time error }

ну уже хорошо

type Object struct { parent *Object } func (o *Object) SetParent(newParent *Object) { return o.parent = newParent // Mutation } func (o const *Object) ReadOnlyMethod() { // You can’t call a function with a non-const receiver // on an immutable receiver „o“ o.parent.SetParent(&Object{}) // Compile-time error }

Странное на самом деле. Сразу не увидел. У тебя что нету разделения на const *Object и *const Object? Непорядок

Я конечно понимаю, что писать const *const Object неприятно, но что поделать, если в го всё мутабельно по дефолту

мммм прям крестами запахло

мммм прям крестами запахло

ну так ведь это реально разные вещи и значат они совершенно разное. const *Object значит что указатель нельзя поменять, а *const Object значит, что память на которую указывает указатель менять нельзя.

ну да, но всё же

Ещё нужно добавить оператор &const

Жесть

Жесть

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

И придётся снова городить костыли, чтобы срезать углы

Странное на самом деле. Сразу не увидел. У тебя что нету разделения на const *Object и *const Object? Непорядок

да вот я и не знаю, стоит ли так усложнять или не стоит. потому-что тогда у нас 3 вариации: 1. "мутабельный указатель на иммутабельный объект" 2. "иммутабельный указатель на мутабельный объект" 3. "иммутабельный указатель на иммутабельный объект" может стоит облегчить сиё дело в Go и если указатель иммутабельный то и объект тоже?

Честно говоря от таких извращенских конструкций чуть воротит

Начинаешь задумываться а надо ли оно))

Начинаешь задумываться а надо ли оно))

надо, иначе бы нам не нужны были типы, компиляторы и т.д. ибо нафиг безопасность!

так

Ещё нужно добавить оператор &const

зачем?

2 и 3 - это одно и тоже, иначе мы с ума сойдем

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

2 и 3 - это одно и тоже, иначе мы с ума сойдем

да, вот да, кстати

вариантов два: 1. мы взяли нечто, и присвоили его иммутабельной переменной. оно стало иммутабельным 2. мы зяли нечто, сделали его иммутабельным и присвоили переменной

2 и 3 - это одно и тоже, иначе мы с ума сойдем

А тут никак, либо только один const *Object, либо добавлять модификатор указателя и появляется 4 комбинации вместо 2-х. Это же комбинаторная логика.

по эффектам это должно быть ± одно и то же

но!

парадигма разная

и мне кажется, что парадигма 2 лучше подходит для go - у нас переменная появляется позже сущности

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

и поэтому я думаю, что константный возврат не нужен

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

почитай мой review, я там пояснил почему таки нужны

инкрементирую последний 2 коммента Подольского

а вот константные указатели нужны

вот собственно почему нужны иммутабельные поля https://github.com/romshark/Go-2-Proposal---Immutability/pull/3#discussion_r214764431

я почитал бегло, и понял, что я не спорить хочу, а обсудить :)

так вот

/start@daysandbox_bot

мне кажется, что моификатор const должен относиться к созданию сущности (инициализации и передаче параметров), а не к хранению

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

хочешь константный возврат - возвращай константное выражение

мне кажется, что моификатор const должен относиться к созданию сущности (инициализации и передаче параметров), а не к хранению

const защищает от мутаций. Если мы знаем что UniqueObject.Identifier не должен меняться в течении всей жизни объекта - мы хотим предовтратить возможные скрытые мутации этого поля в контексте пакета и приватных методов без const полей херово будет, это я вам точно говорю

ну вот это вопрос открытый

ну вот это вопрос открытый

я к тому, что если представить себе относительно большой пакет, над которым работает community, то незаметная мутация приватных полей - может прокотить в каком-нибудь pull request'е, потому-что reviewer'ы всего-лишь люди и могут ошибиться однако если поле const, тогда никто, никогда, нигде не сможет его перезаписать случайно, в этом смысл, полная безопасность

ERROR: S client not available

const защищает от мутаций. Если мы знаем что UniqueObject.Identifier не должен меняться в течении всей жизни объекта - мы хотим предовтратить возможные скрытые мутации этого поля в контексте пакета и приватных методов без const полей херово будет, это я вам точно говорю

Ну это такая себе проблема.

Вообще, как имутабельность реализована в расте?

Ну это такая себе проблема.

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

Вообще, как имутабельность реализована в расте?

Очень удобно. Объявляешь переменную, а она уже иммутабельная, ничего дополнительного писать не надо.

Очень удобно. Объявляешь переменную, а она уже иммутабельная, ничего дополнительного писать не надо.

То есть там просто проверяется наличие где либо попытки изменить ?

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

Вы же хотите оставить го простым языком. Раз так, то реализуйте иммутабельность как у всех языков у которых работа с указателями.

То есть там просто проверяется наличие где либо попытки изменить ?

Ну да, во время компиляции проверяется

да вот нет

с++ - очень плохой пример для подражания

Ну да, во время компиляции проверяется

А с мутабельными переменными также? То есть для всех переменных проверяется можно ли их менять на этапе компиляции?

А с мутабельными переменными также? То есть для всех переменных проверяется можно ли их менять на этапе компиляции?

да

А с мутабельными переменными также? То есть для всех переменных проверяется можно ли их менять на этапе компиляции?

Да, а что не так?

Так а что мешает сделать также в Го?

Зачем все эти ужасы с конст везде?

Так а что мешает сделать также в Го?

обратная совместимость, всё по умолчанию иммутабельным не сделаешь, надо язык менять ломая весь существующий код

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

Оставляем как есть

Зачем все эти ужасы с конст везде?

Ну так компилятору же надо как-то дать информацию о том, что мутабельно, а что нет

Оставляем как есть

как есть?

как есть?

Ложкой

Ну так компилятору же надо как-то дать информацию о том, что мутабельно, а что нет

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

Как в Расте для мутабельных

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

Да незачем, так можно делать только изначально при создании языка.

Что-то в последнее время тут стало много споров и меньше полезной инфы к сожалению

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

Ну так const

Оставим Конст, окей

Зачем все эти конст в параметрах функций?

Зачем все эти конст в параметрах функций?

Это ж основная фича

Чтобы никто не изменил то, что вы передали

Зачем все эти конст в параметрах функций?

чтобы без const оно продолжало работать как работает сейчас

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