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

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

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

почитай мой 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, тогда никто, никогда, нигде не сможет его перезаписать случайно, в этом смысл, полная безопасность

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

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

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

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

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

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

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

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

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

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

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

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

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

да вот нет

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

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

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

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

да

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

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

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

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

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

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

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

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

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

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

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

как есть?

как есть?

Ложкой

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

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

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

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

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

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

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

Ну так const

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

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

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

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

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

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

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

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

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

Только там конст должен быть модификатором указателя. В любом случае данные переданные не по указателю ты не изменишь.

А если изменишь, то не страшно.

да разве

а вот я по значению слайс передал

Мутабельное расшареное состояние - главный источник сложности ПО. Именно поэтому ООП - полное дерьмо, в нём shared mutable state достигает своего апогея. Хотя в го это не актуально, ибо всё состояние приложения хранится (почти) всегда в базе.

Что ты несёшь...

или структуру с указателем внутри

Что ты несёшь...

ну - он не сам, он отцов цитирует

а вот Pawel пришёл, как я и предвидел

и это правда, вообще-то

Что ты несёшь...

Этот вопрос мне хочется задать тебе в ответ на каждое твое сообщение.

и это правда, вообще-то

вернее - правда про источник и вранье про go

Только там конст должен быть модификатором указателя. В любом случае данные переданные не по указателю ты не изменишь.

какие недостатки повлечёт за собой рассмотрение const *Object как иммутабельный указатель на иммутабельный объект?

никаких

Мутабельное расшареное состояние - главный источник сложности ПО. Именно поэтому ООП - полное дерьмо, в нём shared mutable state достигает своего апогея. Хотя в го это не актуально, ибо всё состояние приложения хранится (почти) всегда в базе.

всё состояние хранится в базе?! щито? Go это general purpose language а не SQL

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

вернее - правда про источник и вранье про go

И про ООП враньё

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

согласен

а вот насчет ООП это правда. хер ведь усвоишь, в какое состояние приходит твой объект при вызове метода, и в каком состоянии он находился перед ним. идея была в том, что нам и не надо будет это усваивать. но - не выстрелило

никаких

хммм, чёт я как бывалый C++'щик не совсем уверен

Ну как бы это вполне классический бэк, когда бОльшая часть общих данных лежит в базе и вся забота по синхронизации ложиться на СУБД и транзакции

вернее - высрелило и в цель, и в ногу

хммм, чёт я как бывалый C++'щик не совсем уверен

из плюсов в го, чего так?)

а вот насчет ООП это правда. хер ведь усвоишь, в какое состояние приходит твой объект при вызове метода, и в каком состоянии он находился перед ним. идея была в том, что нам и не надо будет это усваивать. но - не выстрелило

собственно - const methods

из плюсов в го, чего так?)

попиши web API на C++, поймёшь

😄

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

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

Мне приходят в голову примеры с векторами, деревьями, графами и прочими структурами, которые полностью заменять не надо, но надо изменять в процессе.

Но векторов в го нет, ибо они не ложатся на гошную модель работы с памятью.

С графами и деревьями думаю то же самое.

1. immut * to mut Object: const * Object 2. mut * to immut Object: * const Object 3. immut * to immut Object: const * const Object честно говоря не хочется в Go внедрять подобные конструкции

Но векторов в го нет, ибо они не ложатся на гошную модель работы с памятью.

И тут я вспоминаю почему GC в принципе плохо ложится на императивное программирование.

func C1(o const *Object) { o.Mutate() o = nil // Compile-time error } func C2(o *const Object) { o.Mutate() // Compile-time error o = nil } func C3(o const *const Object) { o.Mutate() // Compile-time error o = nil // Compile-time error }

короче я пока-что опишу это с 3 вариациями, но помечу как спорный момент и над ним ещё предспоит вывести решение

из плюсов в го, чего так?)

И правда - чего? Конпиляет полчаса, сообщения об ошибках конпиляции на 10к экранов, сверх сложный, сверх запутанный... самое оно