Если то, что собираешься сделать, не будет меняется, то лучше интерфейс заточенный под это действие наверное

ну вот вопрос именно как лучше это вроде достаточно классическая задача для разработки - использовать преимущества полиморфизма длоя единства интерфейсов но как это делается в go не могу понять; сейчас попробую сделать основу на interface; спасибо

слова* полиморфизм и го не стоит использовать в одном предложении

слова* полиморфизм и го не стоит использовать в одном предложении

Слова полиморфизм, ООП, функциональное, программирование и Go нельзя использовать в одном предложении. (не удержался)

а по вашему вопросу - определите единый интерфейс для ваших структур и работайте уже со слайсом, содержащим объекты с данным интерфейсом

но это же неудобно - я хочу создавать новых "зверей" без модификации "ядра"

https://play.golang.org/p/_ufY7dAcsDR

о, у меня почти также получилось - но здесь даже лаконичнее; спасибо

фаг не успел 🙁

тоже готовил пример и опять затупил

https://play.golang.org/p/S9a8pWN9e1j

"Snake does not implement AnimalInterface" бред какой

"Snake does not implement AnimalInterface" бред какой

потому, что метод определен по указателю

начинает работать когда убираю указатель

а что интерфейсы не работаю без звездочки?

в смысле С звездочкой, не работают

ты в массив пихаешь структуры

а не поинтеры на них

а метод определяешь для поинтера

а что интерфейсы не работаю без звездочки?

Открываю большую тайну. Итак, у нас есть интерфейс. У структуры можно определить метод по значению и по ссылке. Если метод определен по указателю и у нас _указатель_на_структуру_, то он удовлетворяет интерфейсу, если метод по значению и у нас структура по значению, _тоже_удовлетворяет_

в противных случаях - нет

Открываю большую тайну. Итак, у нас есть интерфейс. У структуры можно определить метод по значению и по ссылке. Если метод определен по указателю и у нас _указатель_на_структуру_, то он удовлетворяет интерфейсу, если метод по значению и у нас структура по значению, _тоже_удовлетворяет_

👍

https://play.golang.org/p/HL5e-82ji5g

ну так работает конечно

но ошибка конечно "тупая"

можно было не орать что ""Snake does not implement", а написать что ты не указатель подсовываешь

но ошибка конечно "тупая"

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

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

можно было не орать что ""Snake does not implement", а написать что ты не указатель подсовываешь

Компилятор не знает, почему оно не импементирует, потому и не говорит :) Он он просто увидел, что метод не определен, интерфейсу не удовлетворяет, усё

странно кстати что слайс выглядит как - animals := []AnimalInterface{r,s}

а не animals := []*AnimalInterface{r,s}

мы же храним там фактически указатели

странно кстати что слайс выглядит как - animals := []AnimalInterface{r,s}

еще бывают указатели на интерфейсы

r и s это ссылка на память фактически, должны кормить в []*AnimalInterface{r,s} по хорошему

r и s это ссылка на память фактически, должны кормить в []*AnimalInterface{r,s} по хорошему

А еще ссылка в го не ссылка на память фактически, лол

если мы попробуем таким же финтом хранить кроликов

r1 := &Rabbit{AbstractAnimal{Name:"Bunny", Gender: true},12} r2 := &Rabbit{AbstractAnimal{Name:"Bunny", Gender: true},12} animals := []Rabbit{r1, r2}

то нас пошлют в эротические

что правильно

можно было не орать что ""Snake does not implement", а написать что ты не указатель подсовываешь

Мне помогло осознать, что определение метода в структуре - это, фактически, определение функции, у которой первый параметр - тот, к чему метод привязан. Т.е. func (item Item) SomeMethod(val int) это примерно как func SomeMethod(item Item, val int). Тогда разница с func SomeMethod(item *Item, val int) становится очевидной - просто другая сигнатура функции

ничего им не мешало проверить еще и "соседа"

ибо первый аргумент они сами подсовывают

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

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

ничего им не мешало проверить еще и "соседа"

Так они и так ошибку специфическую подсовывают. Или я неправильно понял?

method has pointer receiver

мне вот не понятно, каким хреном поинтер соотвествует интерфейсу

В смысле?

r := &Rabbit{AbstractAnimal{Name:"Bunny", Gender: true},12} s := &Snake{AbstractAnimal{Name:"Kaa", Gender: false}, 50} animals := []AnimalInterface{r,s}

когда должно быть

animals := []*AnimalInterface{r,s}

Почему?

мы же коллекцию поинтеов определенного интерфейса храним

Мы храним коллекцию интерфейсов.

Поинтеры там или нет пофиг.

это для interface{} справедливо было бы

но мы то храним специфически интерфейсы

И что?

а кормим туда поинтеры

Мы можем и не поинтеры кормить.

Есть полка с книгами, а мы туда карточек напихали "книга лежит на полке №3"

каким образом это соотвествует определению "книга"

это "ссылка на книгу"

поэтому мы должны определится, это картотека карточек или полка с книгами 🙂

нельзя пихать в картотеку книги, в на полку карточки

Полка с книгами - это какой интерфейс?

эти слайз, у него указан в типе BookInterface

Если читать, то карточки не соответствуют и их нельзя туда.

Если только получить имя, то в карточке оно указано и целям удовлетворяет.

причем если без интерфейсов, это работает правильно

r1 := &Rabbit{AbstractAnimal{Name:"Bunny", Gender: true},12} r2 := &Rabbit{AbstractAnimal{Name:"Bunny", Gender: true},12} animals := []Rabbit{r1, r2}

вот за такое стойбище кроликов, нам по рукам надают

поинтеры кормим, где надо структуру

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

и забыл про проверку

Так взаимодействие с ними разное.

Интерфейсы - не структуры и работают с ними по другому.

интерфейс это тип, начнем с этого

поинтер это другой тип

как можно один тип в другой запихнуть?

А структура - это третий.

Какие с этим проблемы. Просто сделан синтаксический сахар, что не надо делать приведение типов.