Кто разбирается помогите понять основу. Есть пакет io

В нем определяется интерфейс reader и соответственно его метод Read
type Reader interface {
    Read(p []byte) (n int, err error)
}

в пакете String следующее

func (r *Reader) Read(b []byte) (n int, err error) {
    if r.i >= int64(len(r.s)) {
        return 0, io.EOF
    }
    r.prevRune = -1
    n = copy(b, r.s[r.i:])
    r.i += int64(n)
    return
}

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

это точно канал про анимэ?

(0) Нет интерфейс Reader и структура Reader из разных пакетов не связаны.

type Reader
A Reader implements the io.Reader, io.ReaderAt, io.Seeker, io.WriterTo, io.ByteScanner, and io.RuneScanner interfaces by reading from a string. The zero value for Reader operates like a Reader of an empty string.

type Reader struct {
    // contains filtered or unexported fields
}

(2)+ Привязка идет по "Read" в Go https://ru.wikipedia.org/wiki/Утиная_типизация

(3)+ Т.е. любая структура которая реализует "Read(p []byte) (n int, err error)" будет иметь интерфейс "Reader".
И неважно какое имя мы дали этой структуре, ну вот захотелось им и обозвали тоже Reader.

r := strings.NewReader("my request")

Тоесть получается тут r структура Но так как у структуры есть метод Read Структура данная является и интерфейсом? или опять я не прав?

(5) Да r тут структура имеющая интерфейс Reader (с одним методом Read).

И везде в другом коде где известно про интерфейс Reader, можно подсунуть r (который фактически реализует этот интерфейс).

(5) Но структура не является интерфейсом!
Она реализует интерфейс, т.у. у данной структуры есть метод (или набор всех необходимых методов) и поэтому она обладает объявленным с этими методами интерфейсом.

(5) эта структура не является, а реализует интерфейс.
указатель на нее можно передать например в такую функцию
func foo(r io.Reader) {

}

r := strings.NewReader("my request")
foo(r)

Например в своем коде ты можешь написать

type MistaR struct {
  // ...
}

func (m *MistaR ) Read(b []byte) (n int, err error) {
    if m.i >= int64(len(m.s)) {
        return 0, io.EOF
    }
    m.prevRune = -1
    n = copy(b, m.s[m.i:])
    m.i += int64(n)
    return
}

А затем имея массив или слайс где внутри хрен знат что или "type Reader struct" или "type MistaR struct" не парясь получив элемент делать element.Read(b)
Или передавать в любой сторонний модуль/код где знают про "type Reader interface" и будут дергать этот метод Read (хотя про твою структуру MistaR там слыхом не слыхивали)

Круто! многое понял Хорошо ответили мне а то бы в неверном направлении пошел Спасибо

https://habr.com/ru/company/mailru/blog/463063/

(11) Еще раз огромное спасибо

(8) Забыл уточнить что внутри "func foo(r io.Reader)" низзя ничего кроме r.Read() делать с r

Т.е. только те методы вызывать которые прописаны у интерфейса io.Reader

(13) конечно, то что можно делать с параметром, определяется его типом - r io.Reader

Небольшое уточнение то есть главный плюс интерфеса в что я в любую функцию с параметрами r Reader Могу передать свою переменную r или MistaR  Например io.ReadFull Я прав?

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

поясните за синтаксис
что за 2 параметра у функции

(17) если вы про (15) То тут https://habr.com/ru/company/mailru/blog/463063/ реально все доходчиво объясняется

это так методы объектов задаются чтоли?

зачем какждый раз придумывают новый синтаксис для типовых вещей?

нет чтоб просто писать
func Reader.Read(b []byte) (n int, err error)

а вместо имени переменной писать this ну или self

(17) Параметр у функции один "b []byte"
"n int, err error" это описание возвращаемых результатов функции

просто,в нормальном языке были бы одни скобки и IN или OUT перед параметрами.

(24) Это лишнее, зачем писать IN и OUT когда порядком скобок все определяется?

(25)+ Немного путано только выходи если функция без параметров но с результатом
func MyFun1()(n int){
}

Если же "процедура" то банально можно опустить вторые скобки
func MyProc1(){
}

(24) вторые скобки описывают _тип_ возвращаемого значения. Или, если угодно, контракт. Написано ([]int, string) - значит функция обязуется вернуть массив целых и строку. И ничего иного. Компилятор проверит.

(27)+ причём, компилятор проверит, что любой return возвращает что надо, и там, где функция вызвана, готовы принять то, что она вернёт

(27) Он подразумевал что IN или OUT в одних скобках, как ByVal или ByRef
func (m *MistaR ) Read(IN b []byte, OUT n int, err error) {
}

Да такой вариант синтаксиса вполне рабочий но не в Golang

(1) это уже давно не форум по 1С. Люди массово валят. Теперь в go.

Вообще более конструктивно здесь создать канал поддержки продуктов от Smartbear и Atlassian

(30) Smartbear можно для работы с 1С применять?
Atlassian знаю что юзают, первый бит например на их продуктах сидят плотно.

(30) создай, это недорого. Фузинята не дадут соврать.

(32) И почем оптом если отдельный раздел с неограниченным числом веток?

(33)+ И это личка/админка с автооплатой и автовыставлением счетов есть уже?

(33)+ И главное API не забыть для автоматизации модерирования и холивара накидыванием новых постов программно.
Чтобы AI прикрутить на ML.

Я так понял интерфейсы нужны для составных типов - аналог 1С. В go строгая типизация, и что бы обойти это нужны интерфейсы.

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

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

(36) Не совсем так. С помощью интерфейсов в go (и не только) реализуется полиморфизм. Проще говоря, компилятор может проверить, что то, что прилетело в функцию, будет иметь свойства и методы, которые в этой функции используются. Чтобы получить ошибку типа одинесовского "Значение не является значением объектного типа" в go надо сильно постараться.

(37) В go функции очень хорошо подставляются в выражение. В go вдоль и поперек пишут такое:

res, err := someFunc()
if err != nil ...

Более того, поскольку в go функции первого класса, то вполне возможны такая конструкция:

func someF(initialState string) func(next http.Handler) http.Handler {...} - функция возвращает функцию, которая принимает и возвращает http.Handler

(39) Из языка стремительно делают write-only язык...

а получается что в го никак не контролируется что объект соотвествует интерфейсу?

(40) в жс тоже можно писать
[а, b, c] =myFunc()

(42) А никто не говорит, что жс - хороший читабельный язык ))

(41) В Go нету объектов по сути, есть экземпляры типов (структур).
Контролируется что если методы который реализованы для структуры соответствуют некоему интерфейсу, значит эта структура и все ее экземпляры имеют этот интерфейс.

(44)+ Т.е. не надо явно и заранее иерархию выстраивать классов или явно интерфейс прописывать-реализовывать.

Можно ваще ход конем сделать, взять любой чужой тип (структуры) и накрутить требуемые для интерфейса методы - опс чужой тип заимел нужный интерфейс и можно куда то подсунуть.

(44) вопрос в обратном порядке.
вот в интерфейс добавили метод, как узнать что все объекты-структуры сломались?

(46) компиляция не пройдёт

(47) а как он узнает, что структура реализует интерфейс?

типа если я реализую 1 функцию из интерфейса, то должен и все?

(49) Не должен, но если хочешь чтобы структура реализовала данный интерфейс надо да все "функции" (методы) реализовать из этого интерфейса

(48) Это называется "утиная типизация". В go ты явно нигде не указываешь, что "структура реализует интерфейс", в отличие от тех же java/c#.
Но если структура реализует методы интерфейса, то считается, что структура реализует интерфейс. Соответственно, её можно использовать там, где программа ожидает этот интерфейс.

(50) *чтобы структура имела данный интерфейс

(51) (52) забавно, типа я написаел 100500 ф-ций с этим интерфейсом, потом добавляю какоето новое поле в него (но ф-ции не меняю), всё хоть развалится при компиляции?

(53) Конечно развалится, ошибку напишет при попытке скомпилировать.

(53) Ну да. Развалится при компиляции, но не в реалтайме.

чтото мне сложно понять как он узнает что ф-ция имплементирует какойто интерфейс

если его явно не указывать

(56) (57) Виртуальная табличка строится

(58) "Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, и есть утка."

(56) имплементирует структура, а не функция.
а узнать это просто: интерфейс - суть список имен. у структуры тоже есть список имен. сравнить два списка занятие нехитрое

(58) а если у меня динамический вызов процедур, он магически догадается что я именно эту процедуру по именно этому интерфейсу вызову?

(59) красиво звучит, но в яве тоже самое но там надо писать implements

(61) Функции не имеют интерфейсов см (60)

(61) процедуры тоже типизированы

т.е такой код будет валиться
type Reader interface {
    Read(p []byte) (n int, err error)
    Write(p []byte) (n int, err error)
}

в пакете String следующее

func (r *Reader) Read(b []byte) (n int, err error) {
    if r.i >= int64(len(r.s)) {
        return 0, io.EOF
    }
    r.prevRune = -1
    n = copy(b, r.s[r.i:])
    r.i += int64(n)
    return
}
ибо не реализован метод Write, так?

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

(62) Неа в яве как и в C# (там утиная типизация сторонними хаками только) и прочих многих явная типизация через implements.

Там ты если написал implements то обязан все методы из него реализовать или ошибка компиляции.
В Go же не надо писать implements, но если ты реализовал все методы из него то считается что виртуально "написал implements"

по мне так строгое указание все-таки нагляднее

(68) вот +100500... мозг конечно ломается на том что они выкинули классы и пытаются странными магическими пассами реализовать их функционал

(62) Ну да. В java явная реализация интерфейсов. Но в go гибче.
Допустим, у тебя есть два интерфейса, у которых методы частично пересекаются. И структура, которая реализует эти методы. Тогда она реализует и интерфейс1 и интерфес2.

(67) а можно ли не все методы реализовать?

(66) Ыыыы, неа просто у тебя основы алгоритмов и реализаций на низком уровне слабые знания.

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

(72) на самом деле ты делаешь неверные выводы лишь по тому что тебе оифгеть как го нравится, а комуто не нравится

(71) можно. но тогда структура не будет реализовывать интерфейс

(71) Можно не все, но тогда считается что интерфейс не реализован еще.
Но возможно реализовав не все методы ты уже сделал некий другой более простой интерфейс.

(72) в рантайме никаких интерфейсов нет

(70) в яве тоже можно делать несколько интерфейсов какбы

(74) но тогда не понятно как компилятор узнает, что стурктура перестала реализовывать интерфейс

(76) Речь не только про интерфейсы но и про слайсы на которых многие срезаются и недопонимают и еще кучу моментов.

(78) Я же написал - сравниваются списки имен

(72) < явно показывают программеру как оно реально работает>
реально не существует ни функций ни объектов, есть поток комманд с условными и безусловными переходами

(78) Виртуальная таблица интерфейсов не будет содержать структуры и структурам не присвоится признак реализации интерфейса при компиляции

(80) вопрос в том а как он понимает что должна была таки реализовать?

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

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

(83) так у тебя объявляется переменная или параметр типа интерфейс. потом ты присваиваешь что-то переменной. компилятор сравнивает ожидаемый набор имен из интерфейса с набором имен того, что ты пытаешься запихнуть в переменную

те пока не использую где-тодальше все норм.
как начинаю использовать получаю ошибку

(85) <потом ты присваиваешь что-то переменной>
так это может происходить неявно

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

(87) Это как это неявно?

(89) ну в го например есть динамический импорт библиотек?

пример кода приведи на питоне хотябы

ну вот на яве, может конечно на го такого не бывает

берем массив типа A=Set<Object> суём туда кучу всякого, а потом вызываем через ((IMyinterface)A).myvoid()

Есть "пустой" интерфейс, которому удовлетворяет всё. Ещё есть рефлексия. Но это настолько явный способ выстрелить себе в ногу, что ты уже должен четко понимать, что ты делаешь.

(92) *во кстати, этож пример утиной типизации в яве

(92) ну на такое явно компилятор нигде не ругнется

ну да...на самом деле действительно implements не особо нужен, хотя наглядность падает

как в 1с практически

У неявного implements  есть большой плюс - если у тебя уже есть какие-то объекты из сторонней библиотеки, и понадобилось вдруг добавить свои, но так что бы и свои, и чужие, реализовывали общий интерфейс - просто описываешь нужный интерфейс, и все, не нужно в чужой код лезть, что бы туда явный implements добавить.

(97) В 1С вообще не так. В 1С навернется в рантайме, если ты где-то там к чему-то несуществующему обратился.

(100)