>>>>Вот по этой вашей фразе я, видимо, имею право предположить, ...
>>Нет, не имеете.Отлично! Из вашей фразы "Да, переприсваиванием исходной переменной, в которой указатель на данные может измениться, а может и нет, изменится поле len, и возможно изменится поле cap" я не имею права предположить, что вы считаете, что поле cap может измениться, и что внутрь слайса может лечь указатель на новый массив? Реально я не имею права предполагать, что если вы говорите "внутри существующего слайса при append'е может измениться указатель на массив и значение поля cap", вы считаете, что внутри существующего слайса при append'е может измениться указатель на массив и значение поля cap? Ну, круто, чо.
Поясню, что в вашей фразе не так. Значение поля cap при append'е в слайсе НЕ меняется. И указатель на массив внутри НЕ меняется.
Вы же, вроде, аналогии с vector'ом проводили? Ну вот, собственно, слайс НЕ вектор. И ключевое отличие ИМЕННО в том, что вектор - динамическая обертка над массивом. При аппенде ВНУТРИ вектора может измениться указатель на массив. Т.е. при реаллокации о копировании содержимого у вас остается ТОТ ЖЕ САМЫЙ вектор, внутри которого лежит ДРУГОЙ массив.
А в Go у вас ДРУГОЙ слайс, внутри которого лежит указатель на ДРУГОЙ массив. Понимаете, в чем разница, и почему таки slice1 = append(slice1, 1)?
Я так и понял, что вы заметили кострукцию, которую видели в соседнем языке, и предположили, что она работает так же. Ну вот нифига, указатель на массив внутри слайса константный, слайс НЕ УМЕЕТ ресайзить массив. Сбоку от всего этого (не внутри слайса, не инкапсулированное поведение, а именно сбоку) есть отдельная конструкция append, которая пишет значения в слайс и возвращает его, или, если слайс слишком маленький, создает новый слайс, и возвращает новый.
У плюсового вектора это поведение ВНУТРИ объекта, а у гошного слайса - СНАРУЖИ. Поэтому вектор - это динамический массив (потому что САМ умеет ресайзить массив), а слайс - представление над статическим массивом (потому что САМ не умеет ресайзить массив, за него это append делает).
Почему вы спроецировали поведение вектора на слайс? Ну, видимо, нужно вернуть вам ваши слова: "Не знаю, возможно недостаточная гибкость мышления, не позволяющая полноценно осваивать новые концепции и вынуждающая страдать синдромом утёнка"
>> В терминологии и концепциях Go нет ни объектов, ни тем более view.
>> Достаточно авторитетным источником в данном случае будет источник от тех, кто создаёт язык. Ссылка на спецификацию, ну или хотя бы интервью или блог одного из тех, кто его пишет и имеет право задавать терминологию и концепции в данной предметной области. Даже комментарии в исходном коде ЯП возможно подойдут.
Ну, окей, таки поцитируем... Навскидку:
"Like arrays, slices are always one-dimensional but may be composed to construct higher-dimensional objects." (обратите внимание на слово objects) - взято тут https://go.dev/ref/spec, официальная спецификация языка Go.
"""
type T struct {
name string // name of the object
value int // its value
}
"""
Обратите внимание на комментарий name of the OBJECT. https://go.dev/doc/effective_go - официальные рекомендации по бестпрактисам го-разработки от создателей языка.
Там же: " it can be more efficient to construct the object with a single allocation". И про объекты, и даже намек, что оно как-то связано с аллокацией.
Думаю, в коде упоминаний объекта тоже достаточно много. Ну, наверное, потому, что объект - базовая концепция CS, совсем не эксклюзивная для ООП. Более того, объект назывался объектом задолго ДО появления ООП, а Алан Кей (создатель концепции ООП) даже утверждал, что, когда он придумывал концепцию, он вообще не C++ имел в виду.
>> В терминологии и концепциях Go нет ни объектов, ни тем более view.
Ну, объекты я вам уже показал. А про view (абстрагируясь от того, что это не языковая концепция, она несколько в другой плоскости лежит), разрешите таки сослаться на go tour:
"A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array." - вот тут написано, что слайс - это VIEW. Прямо можно побуквенно проверить, перечитать 10 раз, присесть и 4 раза перекувыркнуться, но там все так же будет написано, что слайс - это view, т.е. представление. БУКВАЛЬНО так и написано. И с вашей стороны таки странно давать прямую ссылку на фразу "слайс - это представление" и вдогонку с пеной у рта доказывать, что там ни слова про представление не написано...
>> объектом можно назвать что угодно, и именно потому оно теряет смысл в данном случае
Ну нет же. Класс, например, объектом назвать нельзя... Тип нельзя... Много чего нельзя. Вот функцию можно, но только при условии, что язык поддерживает функции первого порядка. А если не поддерживает, то нельзя. Короче, подскажу: то, что можно положить в переменную, как правило, таки является объектом. Если в переменную положить нельзя - то не объект. Могу еще эвристику дать: если у этого есть адрес в памяти, и вы этим адресом как-то можете воспользоваться - это объект.
То, что, в конечном итоге, более-менее все языки программирования так или иначе пляшут вокруг этой самой концепции объекта, не делает концепцию менее ценной. И то, что в Java той же у вас есть базовый класс с названием object, не делает Java-Object каким-то особенно правильным объектом, на фоне которого объекты (по сути, тупо адресуемые куски памяти), созданные менее-ООПшными языками, менее "объективными". Блин, а JSный object - это объект, в конце концов, или не объект? А в TS? А в спецификации C слово "объект" поищем?
Объект НЕ является ООП-специфичной сущностью. ООП - это один из концептов, построенный вокруг концепции объекта, а собственно объекты - они и в функциональных языках, вы не поверите, таки объекты.
>> В котором исходный посыл был ООП vs "функциональщина" (которой там нет).
Про то, что функциональщины там нет, это, собственно, я и писал...
А главная ловушка, что ООП "функциональщине" строго ортогонален. Блин, если что-то противопоставлять начинаете, противопоставляйте "императивщину" и "функциональщину" - они хоть в одной плоскости лежат, и в какой-то мере антонимами являются. ООП - вообще про другое, блин.
>> Там ещё приводились примеры "доступа к методу" через оператор точки и противопоставлялся ему пример с присвоением через append(), или уже забыли с чего всё началось?
Помню-помню. И я еще тогда сказал, что спор был на уровне "теплое" vs "мягкое". Там один про "функциональный интерфейс" вещал, а второй контраргументировал вектором. При том, что слайс ни функциональным интерфейсом не является, ни к вектору особого отношения не имеет.
