я не пойму проблемы )

Функция короче.

думаю оно не сбилдится

я не пойму проблемы )

Пропала первая персона, где он?

можно пример, я из говноязыков пришел, не очень понимаю до конца

https://github.com/romshark/Go-2-Proposal---Immutability#111-ambiguous-code-and-dangerous-bugs

думаю оно не сбилдится

Это псевдо код, конечно.

Заряд сел подвёл.

https://github.com/romshark/Go-2-Proposal---Immutability#111-ambiguous-code-and-dangerous-bugs

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

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

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

дело в том что pointer aliasing это mutable shared state, а это опасно

есть функция copy она не помогает?

есть функция copy она не помогает?

нет

ну он же не по ссылке копирует

1. копирование это зачастую дорого 2. в слайсе у тебя могут быть указатели, скопировав слайс у тебя по прежнему останется pointer aliasing на хранимое в нём

не понимаю

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

странно

имутебельные типы это copy по сути

и это будет долго

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

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

мы хотим иммутаьбельность гарантируемую компилятором ? если попробуешь мутировать немутабельный тип - компилятор быстро надаёт по пальцам молоточком

имутебельные типы это copy по сути

нет, совершенно нет, воспринимай их как "read only" типы. Их можно читать, но мутировать нельзя

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

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

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

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

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

это серьёзный недостаток языка. Аргументации предостаточно

я наоборот иногда пишу на сях

потому что там проще получить всё неиммутабельное

потому что там проще получить всё неиммутабельное

всмсл?))

всмсл?))

прст

это не серьезный недостаток, если есть простая возможность его избежать (самый первый гугл https://github.com/lukechampine/freeze)

всмсл?))

я часто не хочу иммутабельность

прям вообще нигде

такого "сахара" думаю полно

это не серьезный недостаток, если есть простая возможность его избежать (самый первый гугл https://github.com/lukechampine/freeze)

значит скорее всего вы ещё не дебажили проблемы, которые породил mutable shared state и всё ещё впереди ?

я вот дебажил

я просто копирую данные где надо и по ссылке где надо

но мне часто нужно самому контролировать, что у меня и как

так контролируйте

я в JavaScript и C++ этого наелся вдоволь, так что аж тошнит))

в js не то))

так контролируйте

дык в гошке геморройно как раз(

в жс нельзя копию отдать функции

в жс нельзя копию отдать функции

копию самой функции или копию чего-то дать в какую-то функцию? О_о

копию массива в функцию

можно

только костылём

но можно же

как и в го, сделав копию

как и в го, сделав копию

не, там некрасиво

будет та же имутабельность

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

Я постоянно слышу фразы: вот была бы имутабельность, у меня бы было меньше проблем. Проблема в логике а не в имутабельности, и такой код тесты ловят почти 100%

имутабельность не поможет от ошибок, лишь уменьшит их

я просто копирую данные где надо и по ссылке где надо

жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности. Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код) func TakeSlice(slc []string) сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?... а завтра, одним комитом позже, он уже вдруг мутируется ? а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли? Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? ?

Я прекрасно понимаю что копирование добавляет погрешность в структуру. Но я так же понимаю что если у вас данные (якобы которые ридонли) меняются, это значит что код работает не правильно, и тут имутабельность поможет конечно, но внимательность тоже не стоит уменьшать, ибо в другом месте вам не нужна будет имутабельная структура, а подход будет тот же

это не панацея

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

жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности. Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код) func TakeSlice(slc []string) сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?... а завтра, одним комитом позже, он уже вдруг мутируется ? а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли? Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? ?

а теперь решение: func TakeSlice(slc const []string) этот код не двусмыслен, он однозначен: slc не будет мутирован, это гарантирует компилятор. даже если автор этой функции вдруг ошибётся - у него не скомпилируется. а если он таки намеренно пожелает мутировать slc то ему придётся изменить интерфейс и поломать совместимость: func TakeSlice(slc []string) а это значит что не скомпилируется теперь уже у вас - и вы обратите на это внимание, потому-что передаёте немутабельный слайс туда, где ожидается мутабельный. Вы сразу заметите ошибку и недопустите коварный баг до продакшна.

ага, то же самое произойдет и с &*

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

любое изменение приводит к ошибке

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

const []string это не копия, это всё тот-же слайс, но на нём запрещено выполнять мутирующие операции

2 часа ночи....

const []string это не копия, это всё тот-же слайс, но на нём запрещено выполнять мутирующие операции

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

что тут за холивар?

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

это НЕ копия, товарищь ?

ERROR: S client not available

это immutable reference

это НЕ копия, товарищь ?

вы не правильно скопировали кусочек кода из фразы человека выше func TakeSlice(slc []string) тут прийдет в функцию копия

что тут за холивар?

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

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

и саму структуру с маленькой буквы

и саму структуру с маленькой буквы

тут дело не в защите, дело в копии/ссылке и нужен ли ридонли тип

вы не правильно скопировали кусочек кода из фразы человека выше func TakeSlice(slc []string) тут прийдет в функцию копия

дак неважно скопируется ли сам struct слайса или нет, важно то что массив, на который этот слайс / эти слайсы будут указывать - не будет изменён TakeSlice'ом

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

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

дак неважно скопируется ли сам struct слайса или нет, важно то что массив, на который этот слайс / эти слайсы будут указывать - не будет изменён TakeSlice'ом

тоесть по сути это имутабельный тип? не понимат

Изменить то его можно

Блин, вы меня путаете, это банально копия структуры

тоесть по сути это имутабельный тип? не понимат

да, это именно имутабельный тип. В данном пропосале каждый тип имеет своего иммутабельного собрата, как материя и антиматерия... есть слайс, а есть иммутабельный слайс, есть * Object, а ещё есть * const Object

Блин, вы меня путаете, это банально копия структуры

pointer aliasing, в нём вся проблема, понимаете?

нет, я не знаю что это

нет, я не знаю что это

https://en.wikipedia.org/wiki/Pointer_aliasing

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

слайсы в Go это практически указатели обёрнутые в структуру. Слайсы подвержены проблеме aliasing'а

да, слайсы это указатели

это понятно

вопрос в другом

вы не читали все о чем мы говорили выше?

вы не читали все о чем мы говорили выше?

у меня аналогичный вопрос))

е мае, есть два варианта передачи данных в функцию 1. по ссылке 2. копию данных (бла бла умная фраза, все равно будет копия в итоге) Человек хочет третий, чтоб передавалось по ссылке, но нельзя было изменить, ибо данные нельзя будет изменить

е мае, есть два варианта передачи данных в функцию 1. по ссылке 2. копию данных (бла бла умная фраза, все равно будет копия в итоге) Человек хочет третий, чтоб передавалось по ссылке, но нельзя было изменить, ибо данные нельзя будет изменить

верно

тоесть я таки читал?

возможно) третий пункт верно уточнён

народ народ, а что за кейс то такой

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

вы где это используете?

ну я веду к тому что обычно третий пункт вашен при криворуких людях которые тупо меняют данные что им дают. И этот вариант можно решить именно вторым пунктом

жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности. Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код) func TakeSlice(slc []string) сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?... а завтра, одним комитом позже, он уже вдруг мутируется ? а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли? Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? ?

@ruelephant

@ruelephant

не понял проблему если честно