Немного новостей из мира Rust

Я вот одного не могу понять. Ну вот нет нормального ООП в Rust-е. Ну нет. И вроде бы никого это не парит.

Так чего прибегать к аргументам из категории «зато у вас негров линчуют ООП вааще атстой!» ?

Ну реально, говорили бы Rust-оманы прямо: «Нам, чтобы в очередной раз переписать grep и сделать экспериментальный модуль в ядро Linux-а, ООП не нужен» ну и всех делов. Так ведь нет, обязательно нужно попытаться обмазать ООП известной субстанцией, даже не замечая, что эта субстания извлекается из собственных шароваров, т.к. из-за незнания ООП обосратушки-то и приключаются.

Ну самое простое решение это не использовать такой паттерн потому что он нарушает инкапсуляцию :)

Нет, не нарушает.

Человек который писал класс my_basic_subscriber расчитывал что вызовет его метод cleanup а будет вызван совершенно другой метод который непонятно что сделает и может нарушить инварианты оригинального класса

Нет, это ваши предположения чтобы натянуть сову на глобус.

Если cleanup объявляется в самом базовом типе как чистый виртуальный метод, то значит изначально производным классам дается возможность полностью адаптировать cleanup под себя.

Или наоборот минимальные изменения в реализацию базового класса (например если мы уберем вызов cleanup в методе subscribe) могут поломать далекого наследника который в своей логике расчитывал что subscribe всегда вызовет cleanup.

Если это наследник именно my_basic_subscriber, то сам факт наследования от my_basic_subscriber указывает именно на то, что наследник завязан на поведение my_basic_subscriber::subscribe. И если поведение меняется, то да, это сказывается вообще на всех.

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

Это уже прямо явное нарушение инкапсуляции потому что приватная реализация базового класса

Здесь нет приватной реализации. Метод cleanup объявлен в private части для того, чтобы его клиенты класса не могли напрямую вызывать (здесь я ошибся, нужно было в protected части объявлять, но это следствие того, что код писался сходу и компилятором не проверялся).

Для наследников cleanup – это вполне себе доступная ручка, которую запросто можно крутить для тонкой настройки. Ведь в C++ наследник запросто может переопределить даже приватные виртуальные методы базового класса (если они не были объявлены как final на каком-то уровне наследования).

Смотри википедию Fragile base class

То, что дети засовывают отвертки и шпильки в розетки не значит, что розетки плохи.

Вот точно так же и с поддержкой ООП в продвинутых статически-типизированных языках, вроде C++, D или Eiffel. Вы можете сделать что вам нужно, но ответственность на вас.

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

А я бы вам сказал, что скорее всего вы программировать толком не умеете.

Т.е. твой код можно представить так:

Нет, нельзя.

Даже элементарно класс описать можно только стоя на лыжах в гамаке.

Слушай, сколько «классов» ты написал на Расте? 🤣 Адепты ООП хуже адептов любого ЯП: нельзя же парадигму программирования считать безальтернативной, это всего лишь архитектурный подход.

А я бы вам сказал, что скорее всего вы программировать толком не умеете.

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

Я вот одного не могу понять. Ну вот нет нормального ООП в Rust-е. Ну нет. И вроде бы никого это не парит.

Так чего прибегать к аргументам из категории «зато у вас негров линчуют ООП вааще атстой!» ?

Эта тирада была бы более убедительной, если бы тема была не про Раст и не плюсовики прибежали сюда со своим ООП.

В остальном ты ставишь телегу впереди лошади: это не ООП отстой потому что его в Расте нет, это в Расте нет ООП, потому что оно отстой. Раст просто проектировался тогда, когда всё с ООП стало в общем-то ясно и Раст не пытается делать вид, что он C+=2 какой-нибудь, поэтому может себе позволить убрать очевидную каку из языка.

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

И вот в этом контексте и вышел Раст, дитя своего времени, который это самое ООП загнал глубоко под шконку, оставив маленький кусочек в виде динамической диспетчеризации. С ним тут ругаться бессмысленно, репутацию ООП разрушили до него.

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

Слушай, сколько «классов» ты написал на Расте?

Зачем это делать, если можно взять почти любой случайный ЯП, и написать там class { }. А вы пишите без ООП, я не возражаю. Можно ещё правую руку привязать к ноге и программировать одной левой. Много написали то уже продакшена на расте?

Слушай, сколько «классов» ты написал на Расте?

Зачем это делать, если можно взять почти любой случайный ЯП, и написать там class { }

Go, например? 🙃 Вообще, чтобы о чем-то рассуждать, надо его попробовать на вкус.

А вы пишите без ООП, я не возражаю. Можно ещё правую руку привязать к ноге и программировать одной левой.

Ограниченный ты человек 😁. Скучно с тобой. Нет Бога, кроме ООП, и Страуструп пророк его.

Много написали то уже продакшена на расте?

Нисколько! Сидят рустеры и плачут, что class нет — ну как можно хоть что-то написать 😢.

Вообще у плюсовиков на наследовании слепое пятно: в виду отсутствия в языке интерфейсов,

давай я тебе просто напишу интерфейс на с++:

class Printer {
  virtual string model() = 0;
  virtual void print( string text ) = 0;
}

это интерфейс принтер с двумя методами и каждый кто, его наследует обязан реализовать оба. такая штука некоторых языках наивно наывается interface, хотя называется по науке - «чистый абстрактный класс» (pure abstract class)

https://en.wikibooks.org/wiki/C%2B%2B_Programming/Classes/Abstract_Classes/Pure_Abstract_Classes

Авторы Go и Rust не скрывают, что создали языки с заведомо низким порогом вхождения, поэтому в них ООП есть, но оно куцее

мощь с++ тут в том, что абстрактным обьявляется метод, а не весь класс. то есть можно иметь как чисто интерфейсы(если все методы класса абстрактны «= 0» ), так и смешанные - где часть методов абстрактна, и часть - виртуальна, но не абстрактна, то есть отражает поведение по умолчанию.

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

Например в core Harbour имеется возможность создания «драйверов» для работы с источниками данных.

Каким образом?

Имеется struct, содержащий ссылки на функции (заданы конечно определения функций), а реализация их может быть разная для разных «драйверов».

и вообще, немного истории.

интерфейсы это стыренные явой из c++ «чистые абстрактные классы», просто переименованные в interface.

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

мощь с++

Кстати, а в чём моща измеряется? В WTF в секунду?

Эта тирада была бы более убедительной, если бы тема была не про Раст и не плюсовики прибежали сюда со своим ООП.

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

В остальном ты ставишь телегу впереди лошади: это не ООП отстой потому что его в Расте нет, это в Расте нет ООП, потому что оно отстой.

ООП – это инструмент. Инструмент может подходить под задачу (GUI яркий пример), может не подходить.

Если инструмент не подходит, то его просто не используют.

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

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

Говорить, что «ООП отстой» – это тоже самое, как говорить, что GC отстой или ручное управление памятью отстой. Или что проверка выхода за границы массива отстой, или что отстой – это отсутствие таких проверок.

В каких-то задачах GC работает замечательно, в каких-то от него избавляются (на тех же Java/C# пишут решения для HFT, и там обходятся без GC).

С реализацией ООП та же самая история.

Если мы находимся в рамках статически типизированных языков, то мы можем иметь ООП а ля C++ или а ля Java, или а ля Go. Я бы предпочел иметь хотя бы ООП из C++, но уж точно не ООП из Java.

Но Rust не может предложить даже того, что есть в Java.

Это объективно.

Почему у кого-то от этого пригорает так, что приходится бросаться лозунгами «ООП отстой» – хз.

Ты можешь не верить, но примерно через 5 лет после начала популяризации ООП первая восторженность пропала

Год сможете назвать?

Кстати, а в чём моща измеряется?

В глубине и ширине дерева наследования :)

Go как раз не надо брать, а так-то трудно найти мейнстримный язык без ООП.

А знаешь, почему? Потому что ООП это мэйнстрим и есть. Популярное, попсовое, раскрученное. Поколения погроммистов учили ходить приставными шагами и теперь, невероятно, они хотят так ходить добровольно 🙂. Всё, что ты описал — это следствие. Только у хаскеллистов или лисперов свои религии. Уверен, будь они популярнее, тут бы доказывали, что без монад печатать «привет, мир!» могут захотеть только конченные идиоты, или что single-dispatch для убогих, сознательно отказывающихся от мультиметодов.

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

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

Имеется struct, содержащий ссылки на функции (заданы конечно определения функций), а реализация их может быть разная для разных «драйверов».

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

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

то есть плюсовый обьект переведенный в сишный будет выглядеть как:

struct SomeClassWithVirtualFUnctions {
  this_class_type_descriptor *_type_descriptor; ///это указатель на дескриптор класса с таблицей вирт методов
  
  int _user_field0;
  int _user_field1;
...
}

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

https://github.com/AnthonyCalandra/modern-c-features

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

Собственно, это классическая реализация ad-hoc полиморфизма и ООП, которая много где используется, независимо от ЯП.

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

Код, работающий с интерфейсом некоторого объекта, может вообще ничего не знать о данном объекте, кроме того, что объект реализует заданный интерфейс. (Эту информацию можно получить в рантайме.)

Собственно gtk мог бы быть намного более гибким и универсальным тулкитом, если бы там возможности этого ООП использовались по максимуму в рамках разумного подхода к проектированию программных интерфейсов виджетов.

Но там слишком много было сделано по типу «и так сойдёт». Там, где следовало бы использовать интерфейс, вместо этого делали базовый класс; а там, где базовый класс - хадкодили какой-нибудь код. Потом от этих ошибок уже не избавиться без слома совместимости.

Собственно, это классическая реализация ad-hoc полиморфизма и ООП, которая много где используется, независимо от ЯП.

ей не перешебить семантику ооп в c++.

1. в c++ есть понятия конструктора/деструктора вызываемых автоматически. что дает все преимущества RAII, а также избавляет от ручной работы, где можно ошибиться.

2. заполнять таблицы вирт методов с++ будет автоматически.

3. с++ переопределяет операторы.

4. есть public/protected/private

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

Кроме п.1, остальное чисто синтаксический сахар.

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

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

В плюсы же завезли модули

Я еще в 2015-м живу)

Ну, как бы тебе простительно, потому что ты всего лишь глупый плюсовик. Нет, это не интерфейс, это класс. За объяснениями - к Даниэлю Канеману или к Дэну Ариэли.

Слишком толсто даже для меня. И это при том, что я в вейландосрачах участвую.

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

не не не, паждите. насчет пункта 2. а кагжы совсем еще недавнее яростное сопротивление адептов «не нужна нам эта ваша спецификация, куда хотим туда и развиваем!» . правильно ли я понимаю что щас весь вектор накала будет развернут в сторону «у всех нормальных ЯП есть спецификация!» ?

интерфейсы это стыренные явой из c++ «чистые абстрактные классы», просто переименованные в interface.

Нет.

Это принципиально разные концепции, реализованные примерно тем же механизмом.

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

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

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

все тебе только спасибо скажут в ответ.

Плюсовики просто используют ООП наряду с другими доступными в C++ парадигмами и пользуются теми преимуществами,

бла-бла-бла. С пропагандой вашего протухшего ООП куда-нибудь в другое место, пжалста.

ООП – это инструмент. Инструмент может подходить под задачу (GUI яркий пример), может не подходить.

Это ложь. ООП - это не инструмент. Инструмент - это динамическая диспетчеризация, например.

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

И это всё уже лет 10 как лежит на свалке.

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

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

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

Потому что ООП это мэйнстрим и есть.

А почему так? На любимые рептилоидами монады у людишек мозгов не хватает наверно. Теперь вот хитрый заход с растом. Такой хаскель для тупых. Но тоже как-то не пошло. Может просто гуманоидам ООП удобнее и понятнее? Не?

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

Ну хорошо. Вот возьмём типичного плюсовика, типа тебя. Скажи, ты когда-нибудь составлял реальную статистику, что тебе из «ооп» реально нужно?

Нет.

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

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

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

Как-то так.

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

давай ответ, без воды, кроме которой пока ничего нет.

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

Ну перечитай.

Раза с 5го должен понять по любому.

Ну а чтоб тебе было с чего начать, задай себе вопрос, зачем люди, умнее тебя на 2 головы, решили что чистые абстрактные классы надо переименовать?

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

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

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

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

никому не нужного ООП.

Во-первых, отучаемся говорить за всех.

Во-вторых, вы пропердели выше что-то про «примерно через 5 лет после начала популяризации ООП первая восторженность пропала». Год назвать можете?

А почему так?

Честно признаюсь, что я слишком тупой, чтобы ответить на этот вопрос 😊, вкратце (не буквально, но сойдет).

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

Ну нет. Если начать читать даже хороший учебник по хачкелю, то вскоре доберешься до какого-нибудь Клейсли и подумаешь: «Да что, черт возьми, это такое вообще?!», - а потом отправишь учебник к такой-то матери. С официальной книгой по Расту такого чувства не возникает нигде. Нет никаких НЁХ, которые непонятно для чего искусственно вводятся, нет чувства отторжения, даже от борроу-чекера.

Может просто гуманоидам ООП удобнее и понятнее?

Удобно то, что привычно. Начни решать задачи на Расте, используя методы, которыми принято их решать на Расте, привыкни и тебе станет удобно. К примеру, это не агитация 😄. В конце концов, люди на Лишпе пишут, а тут довольно обычный ЯП, ну, по рукам бъет, потому что заставляет понимать, как создаются и живут данные в твоей программе. А удобнее/неудобнее… У тебя говорит накопленный бэкграунд, ты не нуб, который первый раз палкой трогает кодинг, чтобы объективно рассуждать, что удобнее. Конечно, тебе удобнее искать кейворд class и от этого плясать.

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

Простите, возможно, столь эмоционально мне нужно было отвечать не вам. Просто так получилось.

По поводу возможностей Rust-а тут, на LOR-е, в одном из срачей было показало, что реализация Rust-а отвечает целям создателей и что другие подходы, скорее всего, в Rust-е с его borrow checker-ом, не были бы реализованы вообще.

Подробностей не помню, к сожалению, дело было лет пять назад, если не больше.

В принципе, меня это удовлетворило и к Rust-у отношение ровное: ну вот здесь так, что хотели и могли, то и сделали. Для многих задач хватит за глаза, для каких-то задач не хватит, значит они будут решаться на Rust по другому (или будут решаться не на Rust-е).

Во-первых, отучаемся говорить за всех.

Слив засчитан. Поздравляю

Во-вторых, вы пропердели выше что-то про «примерно через 5 лет после начала популяризации ООП первая восторженность пропала». Год назвать можете?

Точно не могу, не за всеми публикациями следил. Liskov principle слышал? Вот, это пример одной из таких публикаций, причём это не васян написал «ой, чёт я обосрался как-то», это умная баба сформулировала вполне разумное ограничение на наследование. Википедия говорит что первое упоминание где-то в 87 году.

кашу заварили явщики. они боялись множ. наследования с++ как огня

нэ савсэм.

фича в чем. Во времена явы всем уже давно был известен тот простой факт - о котором множество разработчиков языков забывает - что программист в основном читает код, а не пишет. И ява во многом сделана не для того, чтобы на ней писать, а чтобы на ней читать. Отсюда развесистая многословность, отсюда практически никаких сокращений а-ля fun/num/fmt/итд, отсюда никаких широко распространенных ^%>>|$#, как-то там превращающихся в элегантные шорты в зависимости от контекста - да и вообще зависимых от контекста языковых элементов, нету там «const значит вот это, const * уже это, const & вот так, а &const эдак».

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

Слив засчитан. Поздравляю

Да ради бога, сколько угодно.

Liskov principle слышал?

Вы сейчас про Liskov substitution principle?

Википедия говорит что первое упоминание где-то в 87 году.

Т.е. в 87-ом начали писать про то, что постоянное наследование не есть хорошо? Правильно я вас понял?

Я не собираюсь тратить своё время по 5 раз объясняя очевидные вещи. Есть что возразить?

Вам сложно подтвердить, что речь идет именно о Liskov substitution principle? Может вы еще что-то имеете в виду, вы же такой загадашный.

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

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

то есть с точностью до имен это строго одно и то же.

какой нибудь на псевдокоде

interface Named {
  name(): string
}

на c++ это

class Named {
public:
  virtual string name() = 0;
}

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

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

Честно признаюсь, что я слишком тупой

доберешься до какого-нибудь Клейсли

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