Пара общих вопросов: Каковы недостатки реализации наследования в Go через embedding? Чем

отличаются в поведении небуфферизированный канал и канал с буффером размера 1?

Недостаток в том, что встраивание — это не наследование. Он не работает как наследование

Это преимущество же

Ну, я цитировал вопрос

небуферизированный создается с размером 0. ну а разница как между буф и небуф каналами)

И принцип Лисков мягко говоря не про это

superclass object should be replaceable with a subclass object Это принцип Лисков, и именно про это я и писал. Встраивание не позволяет нам нигде пропихнуть результат через аргументы, где принимался как аргумент "родитель"

если это встраивание интерфейсов, то кое где позволяет

Это не принцип Лисков. На английском он звучит как "Let {\displaystyle \phi (x)}\phi (x) be a property provable about objects {\displaystyle x}x of type T. Then {\displaystyle \phi (y)}{\displaystyle \phi (y)} should be true for objects {\displaystyle y}y of type S where S is a subtype of T"

ООП в целом мало имеет отношения к прицепу барбары лисков, именно поэтому у всех такие трудности с пониманием что это такое

Так будет в читаемом виде точка зрения донесена?

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

Его почему-то пытаются с SOLID занести в C++/Java и коеят похожие слова. Вот прямо сейчас легкое гугление показало

Это не точка зрения. Это была прямая цитата.

Duck typing = liskov principle?

нет 😄

а разве liskov substitution это не про контракты?

Ну тогда возвращаюсь к своей вопросу.

вот LSP type Parent struct {} func (p *Parent) Go() {} type Child struct { Parent } func test(obj) { obj.Go() } func main() { test(parent{}) test(child{}) }

https://dave.cheney.net/2016/08/20/solid-go-design У Dave Cheney тут в том числе про Liskov Substitution Principle

Не надо постить сюда скриншоты кода и аудиосообщения. Долго – это хорошо, потому что пока делаешь небольшой пример, чтобы вынести в плейгроунд – проблема часто находится

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

Because io.Reader‘s deal with anything that can be expressed as a stream of bytes, we can construct readers over just about anything; a constant string, a byte array, standard in, a network stream, a gzip’d tar file, the standard out of a command being executed remotely via ssh. And all of these implementations are substitutable for one another because they fulfill the same simple contract.

Это всё вполне решается текстом или ссылкой

Есть тип А, вы создаете подтип Б от А, любая функция которая работает с А может использовать Б тк это подтип, все. Весь принцип. В контексте ооп это не очень понятно, потому что в ооп когда вы наследуете вы создаете супертип с большим функционалом, те все наоборот.

.