https://groups.google.com/forum/#!topic/golang-nuts/4V3eI4dp95c

Да, я думал, что только в России на форумах полно идиотов (ЛОР является чудесным исключением - спасибо тебе, ЛОР!) Оказывается, и «цивилизованном мире» идиоты преобладают.

Но это было писано в 2009 году. С тех пор проблема так и осталась нерешённой?

Не думаю, что как-то решается, учитывая, что интерфейсы в Go реализуются неявно, и перегружать методы нельзя. Оборачивай структуру во врапперы для которых и реализуй интерфейсы, но еще лучше просто не используй неудачные ЯП.

И какая реализация метода должна вызываться при вызове экземпляр.Извлечь()? Мои действия: делегировать реализацию интерфейсов отдельным полям структуры.

Это ж golang, он весь такой.

Ну, как костыль сойдёт вроде, но нужно не забывать отправлять правильное поле в правильную функцию. Иначе мы попытаемся извлечь аудио блоки из очереди видео блоков (для метода «Извлечь» нас спасёт тип буфера, но метод «ОчиститьОчередь» точно может быть вызван ошибочно, т.к. ничего не вернёт).

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

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

А кто сказал, что «should»? Это лишь чья-то точка зрения. Вот в голанге тоже говорят, что интерфейсы не «should» быть одноимёнными. Но это же не значит, что это правда.

И там даже есть пункт «drawbacks». Я нахожу наследование полезным, но тут дело вовсе не в этом. Пр-во имён методов в golang глобально, и нет никаких инструментов, чтобы его разбить на части. Это явное препятствие для масштабирования.

This

Используй Ada, бро!

Если я правильно понял проблему, то как-то так: https://play.golang.org/p/DSYi94f5GQ

Чё-то ты не то написал, https://play.golang.org/p/XBSGIev6lr Про switch на эту тему кто-то уже упоминал, но я так и не понял, в виду невежества :)

Вообще, мне кажется, смысл этих утиных интерфейсов в том, чтобы можно было обучить чужой объект новым трюком. Отдать малыша в секцию футбола. Можно, конечно, сделать это и иными способами. Вот в C# есть «методы расширения»,

https://metanit.com/sharp/tutorial/3.18.php

И там, похоже, как раз и есть решение описанной проблемы, к-рая в golang, как я понял, всё же не решена.

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

Т.е. я уже стал склоняться к тому, что единственный выход здесь - это иметь _разные_ слова ::словари:методы:дай и ::рефлексия:методы:дай . Соответственно, мы определяем не просто функцию контейнер%дай, а функцию с именем [контейнер ::словари:методы:дай] . Дальше вопрос - жизненно ли это с т.з сложности обращения? Вот этого пока не понял. Ведь смысл записи а.б в том, что всё пр-во имён методов типа переменной а подтягивается для поиска смысла б и это очень славная автоматизация. А с моими разными словами получается какая-то мутная ситуация с пр-вами имён. Вроде есть понятие словарь%дай, но чтобы им воспользоваться, нужно ещё проследить, чтобы правильное слово «дай» было проимпортировано. Т.е. смысл записи а.б частично сходит на нет.

В C# это сделать можно, явно указав имя интерфейса, к-рый я реализую. В С++ при множественном наследовании (не ромбовидном) тоже можно (хотя бы в каких-то контекстах) указать, от какого предка я беру метод Извлечь.

Дык а в чем у тебя проблема ? Вон beastie дал тебе отличный пример. Если ты хочешь явно позвать метод родителя из ребенка при встраивании:

type foo struct {
...
}

type bar struct {
...
}

type baz struct {
  foo
  bar
}

func main() {
  var t baz

  t.foo.Do()
  t.bar.Do()
}

Пример от beastie или неправильный, или я что-то не понял -см. мой ответ - я закомментарил код, который вроде должен был выбирать интерфейс, и всё продолжило работать как ни в чём не бывало.

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

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

что отвечают на стартовый топик Кокс И Пик (и присоединившийся к ним Мюландер?)?

Ту да трэш го гоуз ;D

если в референс языка сложно понять порядок разрешения имён - посмотри эталонную реализацию -> будет яснее как оно в данной конкретной реализации -> golang сырцы в системе контроля версий видно как менялся данный(разрешения имён одноименных методов у поглошённых агрегатов с «похожими» интерфейсами) сырец.

последнее не по важности: что отвечают в оффи рассылках?

то ли я не пойму о чём вы, то ли.. вот в хаскеле делаешь qualified import

import qualified Foo.Mod as FMod
import qualified Bar.Mod as BMod

FMod.f1 
BMod.f1

В скале кстати кажется так же сделано, емнип.

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

Если я правильно понял, то:

Пусть модуль Foo определяет интерфейс AFoo с единственным методом без параметров, Hello

Также в нём есть функция SayHello(o:AFoo), которая вызывает о.Hello

Проблема в том, что теперь любой объект из любого модуля, у которого определена функция Hello, считается реализующим интерфейс AFoo. Даже если та функция Hello по смыслу имеет в виду совершенно другое.

В Хаскеле, если я правильно понял, имя Hello относится к какому-то модулю, поэтому данной проблемы нет. Другое по смыслу Hello просто нужно поместить в другой модуль, это не трудно. А в Golang это имя глобально, и в этом-то проблема (опять же, если я правильно понял). Никто не может поручиться, что завтра другой программист где-нибудь в Японии не создаст своё Hello в какой-то библиотеке, к-рая мне послезавтра понадобится.

С двоеточиями обычные функции можно разрулить. А я хотел сделать подобно Golang (не потому, что знал про Golang, а потому, что это вытекает из некоей внутренней логики). И уже имея готовый код, нашёл ряд проблем, в т.ч. и эту.

Проблема в том, что теперь любой объект из любого модуля, у которого определена функция Hello, считается реализующим интерфейс AFoo. Даже если та функция Hello по смыслу имеет в виду совершенно другое.

О, зело «интересное» решение. По-моему, конечно.

Может тебя наведёт на мысли: в скале можно добавлять методы в класс.

Скажем, есть у нас класс (псевдокод)

class MyClass
  method1: MyType
  method2: MyType

object Helpers {
  implicit class MyClassWithMethod3(myCl: MyClass) {
    def method3(): Unit = {
      myCl.method2()
      println("executed method2 and printed this message")
    }
  }
}

import Helpers._

MyClass obj = new MyClass
obj.method3()

instance MyClass AFoo where
  hello = println "hello from MyClass"

instance MyClass AFoo -- используем реализацию по умолчанию

Преобразование будет работать только там где сделан import Helpers._

Спасибо! В C# вроде тоже подобное делается и тоже с ограничением на import. Похоже, что нужно в этом ключе и действовать, вопрос лишь в нюансах. Например, чем вводится имя в область видимости.

Но всё же - неужели в голанге именно так, как я понимаю? Я всё жду, что мне кто-нибудь мозг на эту тему прочистит :) Иначе очень уж ламерский этот голанг.

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

Пока в Яре есть только родовые функции (не принадлежащие классу) и методы расширения. Обычных методов нет. Чтобы создать метод, пишешь функцию ТипₒИмя-метода. Такой механизм понадобился для доступа к полям лисповых структур, но придётся от этого уходить из-за вот этой проблемы конфликтов.

Понятное дело, что если кто то где то в каком то классе (ClassB) определил ф-цию hello то этот класс не считается представителем AFoo пока явно не объявишь ClassB представителем AFoo.

Я пытаюсь написать видео плейер со звуком, и мне нужно реализовать в одной структре оба интерфейса. У каждого из них есть метод Извлечь() без параметров.

...

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

В Go методы не принадлежат интерфейсам, они принадлежат структурам, соответственно нельзя для одной структуры реализовать метод с одинаковым именем и сигнатурой дважды. Интерфейсы описываются как бы «сбоку», поверх этого, по мере необходимости.

Го тебе правильно намекает на то что реализация не может быть и котом и птицей одновременно. И рекомендует использовать композицию.

Ну да, вот так и надо.

вот в haskell так, как оно будет, подозреваю, что если в Go есть квалифицированные имена то можно как-то так же.

Дык я тоже думаю, что должно бы, но никто пока не объявил :) А вот наоборот - да!

если в Go есть квалифицированные имена

Есть.

то можно как-то так же.

Нельзя. Методы в Go не являются top(package)-level-декларациями.

Дык я тоже думаю, что должно бы

Плохо думаешь.

Корвина в игнор, на тему галку, голанг в топку :)

Спасибо!

Пжл, рад что пришлось ко двору.

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

А вот про утиность скажу: кажется, что нужна фича вроде 'пометить как «да и хрен с ним»'.

Т.е. у меня часто такой ход работы: я пишу одну часть (предполагая что будет другая, связанная). Потом принимаюсь за вторую. И вот когда пишу втору, я часто ломаю интерфейсы. Потому что оказывается что несмотря на то что пытался спланировать, всё таки на 100% у меня не вышло. Может это я такой, не знаю.. но всё таки: т.е. для того чтобы скомпилять это дело в рабочее состояние надо пойти и поправить первый модуль. Иногда такие правки тривиальны (вроде того что называлось afoo, а теперь aFoo). Иногда довольно нудны. Вот когда они нудны, хочется забить и не отвлекаться, потому что сейчас сосредоточен на другом. Было бы удобно если бы можно было добавить коммент и сказать «да и хрен с ним». И система попробовала бы собрать «как может».

Скажем в хаскеле можно было бы попробовать игнорировать описанный пользователем тип (т.е. вывести подходящий из контекста) и тело функции заменить на undefined. Т.е. получилась бы функция нужного типа, но кидающая эксепшн в рантайме. Ну а при компиляции конечно предупреждать «у вас тут помечено как хрен с ним».

Кажется, это сократило бы цикл разработки.

В php и javascript вот такая вот возможность делает цикл «поправил-поглядел» очень коротким. Правда там возникает другой ад - пока ты по всем веткам не пройдёшь, быть уверенным что ничего не сломалось нельзя. Очень трудозатратно, просто ад. Без тестов как без рук. Но (юнит)-тесты вместо типов конечно тоже не выход потому что тесты откровенно говоря то ещё говно (из-за необходимости нетривиальной поддержки, фактически такой же как для кода, т.е. стоимость разработки и поддержки растёт так будто кодовая база выросла вдвое или около того), и не факт что риски падают сильнее. Поэтому я поклонник типов и чем типы «круче» (типа интуционисткой теории), тем лучше.

Да, я к чему - думаю что утиная типизация более проблема чем решение. Она конечно позволяет тебе разрабатывать модули без оглядки на другие модули и сокращает цикл «написал-запустил». Но на системе в целом сказывается очень негативно на мой взгляд.

А вот фича «ну его», выглядит для меня интересной. Но это моё мнение конечно.

Кажется, это сократило бы цикл разработки.

Такава всякая ... ... разумность!

понимаешь, анонимус. Проверка типов (на мой взгляд) нужна чтобы сказать «а вот тут неверно».

Это безусловно нужно. Но в определённые моменты бывает удобным сказать «не сейчас, давай сначала с этим разберёмся, а потом вернёмся к тому ворпосу».

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

Полное отсутствие типов это «не ну я точно так не сделаю» и ничего кроме. С этим - к мамке, рассказывай что ты так не сделаешь.

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

И вот когда пишу втору, я часто ломаю интерфейсы.

Мы подошли к теме, которую я пока не хочу обсуждать публично, но в целом я её хочу обсуждать, поэтому самое время для рекламной паузы. Я открыл новый сайт про русификацию, программирование-по-русски.рф , там указаны E-mail-ы. Напиши, пож. мне.

хочешь потестировать мыло))

The response was:

local-part of envelope RCPT address contains utf8 but remote server did not offer SMTPUTF8

Да тестировал, работало. Хотя я думаю, это зависит и от отправителя. А на англоязычный тоже пробовал?

budden73@mail.ru

А преобразовать структуру к нужному интерфейсу нельзя как в Rust?

https://play.rust-lang.org/?gist=20f9864d7c289fd0ba8460f44992d30f&version...

Но это - мина, которая позже рванёт.

Также есть (чужая) библиотека «рефлексия», в ней есть тип рефлексирующий-субъект, у которого тоже есть рефлексирующий-субъект%дай(строка), но по смыслу это означает «дай метаинформацию такого-то типа».

Делай типажи как в расте, они статически определены.

Я так понял, что нельзя привести, но мне, конечно же, лень читать спеки голанга. Те, кто знают, пишут, что нельзя.

Делай типажи как в расте, они статически определены.

Что делать - это уже следующий вопрос, т.к. мне нравится идея отсутствия явной декларации интерфейса и, может быть нужно что-то чуть другое. Но всё равно, спасибо за совет.

может быть так?

Это безусловно нужно. Но в определённые моменты бывает удобным сказать «не сейчас, давай сначала с этим разберёмся, а потом вернёмся к тому ворпосу».

-fdefer-type-errors может облегчить тебе жизнь.

И где тут вывод двух разных строчек, показывающий, что вызвались разные интерфейсы?

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

Спасибо,не знал.

Как будет нормальный доступ к почте -отпишу,сейчас за городом.

И где тут вывод двух разных строчек, показывающий, что вызвались разные интерфейсы?

Тут вызван был метод, который удовлетворяет одновременно обоим интерфейсам. Интерфейс - это поведение. Го не вызывает методы интерфейса, го вызывает метод структуру, которая удовлетворяет определнному инетерфейсу.