История изменений
Исправление den73, (текущая версия) :
Вообще, мне кажется, смысл этих утиных интерфейсов в том, чтобы можно было обучить чужой объект новым трюком. Отдать малыша в секцию футбола. Можно, конечно, сделать это и иными способами. Вот в C# есть «методы расширения»,
https://metanit.com/sharp/tutorial/3.18.php
И там, похоже, как раз и есть решение описанной проблемы, к-рая в golang, как я понял, всё же не решена.
Также следует учитывать, что методы расширения действуют на уровне пространства имен. То есть, если добавить в проект другое пространство имен, то метод не будет применяться к строкам, и в этом случае надо будет подключить пространство имен метода через директиву using.
Т.е. я уже стал склоняться к тому, что единственный выход здесь - это иметь _разные_ слова ::словари:методы:дай и ::рефлексия:методы:дай . Соответственно, мы определяем не просто функцию контейнер%дай, а функцию с именем [контейнер ::словари:методы:дай] . Дальше вопрос - жизненно ли это с т.з сложности обращения? Вот этого пока не понял. Ведь смысл записи а.б в том, что всё пр-во имён методов типа переменной а подтягивается для поиска смысла б и это очень славная автоматизация. А с моими разными словами получается какая-то мутная ситуация с пр-вами имён. Вроде есть понятие словарь%дай, но чтобы им воспользоваться, нужно ещё проследить, чтобы правильное слово «дай» было проимпортировано. Т.е. смысл записи а.б частично сходит на нет.
Исправление den73, :
Вообще, мне кажется, смысл этих утиных интерфейсов в том, чтобы можно было обучить чужой объект новым трюком. Отдать малыша в секцию футбола. Можно, конечно, сделать это и иными способами. Вот в C# есть «методы расширения»,
https://metanit.com/sharp/tutorial/3.18.php
И там, похоже, как раз и есть решение описанной проблемы, к-рая в golang, как я понял, всё же не решена.
Также следует учитывать, что методы расширения действуют на уровне пространства имен. То есть, если добавить в проект другое пространство имен, то метод не будет применяться к строкам, и в этом случае надо будет подключить пространство имен метода через директиву using.
Т.е. я уже стал склоняться к тому, что единственный выход здесь - это иметь _разные_ слова ::словари:методы:дай и ::рефлексия:методы:дай . Соответственно, мы определяем не просто функцию контейнер%дай, а функцию с именем [контейнер ::словари:методы:дай] . Дальше вопрос - жизненно ли это с т.з сложности обращения? Вот этого пока не понял. Ведь смысл записи а.б в том, что всё пр-во имён методов типа переменной а подтягивается для поиска смысла б и это очень славная автоматизация. А тут получается какая-то мутная ситуация с пр-вами имён. Вроде есть понятие словарь%дай, но чтобы им воспользоваться, нужно ещё проследить, чтобы правильное слово «дай» было проимпортировано. Т.е. смысл записи а.б частично сходит на нет.
Исходная версия den73, :
Вообще, мне кажется, смысл этих утиных интерфейсов в том, чтобы можно было обучить чужой объект новым трюком. Отдать малыша в секцию футбола. Можно, конечно, сделать это и иными способами. Вот в C# есть «методы расширения»,
https://metanit.com/sharp/tutorial/3.18.php
И там, похоже, как раз и есть решение описанной проблемы, к-рая в golang, как я понял, всё же не решена.
Также следует учитывать, что методы расширения действуют на уровне пространства имен. То есть, если добавить в проект другое пространство имен, то метод не будет применяться к строкам, и в этом случае надо будет подключить пространство имен метода через директиву using.
Т.е. я уже стал склоняться к тому, что единственный выход здесь - это иметь _разные_ слова ::словари:методы:дай и ::рефлексия:методы:дай . Соответственно, мы определяем не просто функцию контейнер%дай, а функцию с именем [контейнер ::словари:методы:дай] . Дальше вопрос - жизненно ли это с т.з сложности обращения? Вот этого пока не понял. Ведь смысл записи а.б в том, что всё пр-во имён методов типа переменной а подтягивается для поиска смысла б. А тут получается какая-то мутная ситуация с пр-вами имён.