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

Некорректно скриптотню сравнивать с серьезным ЯП по трудности усвоения. Раст не сишка, но и там от байтовой дрочильни никуда не денешься, а если она тебе и даром не сдалась, то всё еще хуже воспринимается 😐. Хотя перл я бы всё равно не выбрал 😎.

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

В расте его нет по более банальной причине.

придумали название интерфейс

Интерфейсы в Яву пришли из Objective-C, насколько помню.

Но тоже как-то не пошло.

Да вроде пошло. Весь гитхаб завален.

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

С «точностью до имён» и struct от class не отличается. Однако все ЯВУ - это вообще говоря именно про то, «как выразить эту идею словами». Про имена явлений.

Сформирована новая команда по работе над официальной спецификацией языка Rust

Только сейчас сформирована.

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

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

По-моему, это честное предложение. Гораздо уважительнее, чем то, чем занимаетесь тут вы.

ООП - это не только слово class.

Какая глубокая мысль

точно! одиночное наследование и множественные интерфейсы - это как минимум objective-c.

Поэтому если я вижу как оппонент вместо того чтоб ответить по существу

По существу чего?

Вот вы сказали:

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

Мне, например, ООП нужно. Я, например, ООП использую.

По существую получается что ваше утверждение «никому не нужное ООП» опровергнуто.

Далее, вы сказали про liskov principle.

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

Если таки речь про «liskov substitution principle», то он был сформулирован в работе от 1994-го года (которую я пока не прочитать не успел, там 31 страница наукообразного текста, так что разговор о первоисточнике вести не могу). А в 1987-ом была опубликована статья Data Abstraction and Hierarchy в которой вводится понятие иерархии типов как семантического понятия. Критики наследования классов там откровенно мало, а к той, что есть, есть вопросы. Более того, Лисков там пишет буквально такое (страница 10):

An inheritance mechanism can be used to implement a subtype hierarchy. There would be a class to implement the supertype and another class to implement each subtype. The class implementing a subtype would declare the supertype’s class as its superclass.

По существу чего?

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

Мне, например, ООП нужно. Я, например, ООП использую.

Скорее всего нет. Ну т.е. не в плане «вот я функцию виртуальную переопределил», а в классическом понимании ООП, ради которой всё затевалось. Напоминаю, ООП - это парадигма программирования. Парадигма, как говорит словарь, это модель познания, в программировании это совокупность идей и понятий, подход к программированию.

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

А то будет некрасиво, если я говорю про «liskov substitution principle», а вы про какой-то другой.

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

Дальше, как я понял, ваше разоблачение касается утверждения «через 5 лет», на самом деле через 7 или даже 10. Мне этот вид дискуссии неинтересен, так как не вносит никаких существенных возражений

Если таки речь про «liskov substitution principle», то он был сформулирован в работе от 1994-го года

Беглый просмотр википедии даёт следующую цитату:

In an influential keynote address[4] on data abstraction and class hierarchies at the OOPSLA 1987 programming language research conference, Barbara Liskov said the following: «What is wanted here is something like the following substitution property: If for each object o_1 of type S there is an object o_2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o_1 is substituted for o_2, then S is a subtype of T.»

И, кажется, я вижу тут 1987

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

Колесо изобрели сколько, тысячи четыре лет назад? Или пять?

Что-то не слышно жалоб на то, что оно вышло из моды.

А сам по себе он нахрен никому не нужен.

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

Скорее всего нет.

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

Но, скорее всего, подобных аргументов с вашей стороны не будет.

Поэтому адрес для вашей пешей прогулки все тот же.

Это если по существу.

Т.е. вы не знаете ни одного другого принципа Лисковой, но нешили включить дурака и потянуть время?

Я, блин, просто дохера чего не знаю в принципе. И дохера чего забыл из того, что знал.

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

Поэтому да, в силу своей ограниченности я предпочитаю явно договориться о терминах.

Беглый просмотр википедии даёт следующую цитату:

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

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

Колесо изобрели сколько, тысячи четыре лет назад? Или пять?

Нинужно, будем летать на антигравитационной подушке. Вот и вместо ООП предлагают что? Кто-нибудь новую парадигму сформулировал? Ну допустим ФП, но раст и тем более Go не ФП языки. Просто там взяли и отрезали себе член, и рассказывают как это удобно и современно.

Колесо изобрели сколько, тысячи четыре лет назад? Или пять? Что-то не слышно жалоб на то, что оно вышло из моды.

Согласен. Более того, есть и более близкие к времени и теме примеры. Структурное программирование, хайп давно прошёл, полвека как никак, и тем не менее все используют и как-то не возникает предложений заменить циклы старым добрым гото. Аналогично можно сказать про процедурное программирование. Что есть общего у колеса и структурного и процедурного программирования, чего нет у ООП? Может то, что они реально полезны?

Ну вот мне нужен. Так что вы со своим «нахрен никому»

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

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

Ну вы сами напросились. Доказываю что вы - балабол на раз-два.

Итак, согласно вашим же словам, в Расте нет ООП, не смотря на присутствие трейтов и динамической диспетчеризации. Также мы помним, что ни трейтов, ни интерфейсов в C++ нет, этот функционал реализуется классами. Следовательно, любое наследование и переопределение в C++ коде, сделанное вами чтоб заимплементить интерфейс, например требуемый API какой-то библиотеки, согласно вашему же определению будет наследованием и переопределением, но не ООП. Ну а место где производилось такое «наследование» вы легко сами найдёте. Доказано.

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

Вы ставите меня в неудобное положение. Я привёл цитату 1987 года, в которой суть принципа Лисковой произнесена. Вы пишете «точной формулировки нет». Что это? С одной стороны, выглядит как очередная попытка юлить и выехать на «но не сформулировала же, значит нещитово». И опыт дискуссии с вами показывает, что подобное поведение вполне у вас в характере. С другой стороны, если предположить, что вы не понимаете, в чём принцип Лисковой заключается, почему он важен, почему ему выделили целую букву в SOLID, то вполне возможно что та цитата ничего вам не говорит. Это довольно странная версия, однако учитывая что именно принцип Лисковой и доказал полную несостоятельность ООП, вполне возможно что именно потому вы и пытаетесь защищать ООП, что тупо не понимаете принципа Лисковой и всей его важности.

Соответственно я не знаю как отвечать. Можно убить кучу времени объясняя на пальцах принцип Лисковой, а потом окажется, что просто читал лекцию троллю. Или можно обозвать демагогом и послать в пешее, а потом окажется что обидел человека, просто за то что он чего-то там не знал.

Так как вам виднее, валяете ли вы дурака или реально не вдупляете, предлагаю выбор сделать вам. Как с вами поступить?

вопрос по русту.

допустим у меня есть c++ и библиотечный класс tree_view, который наследует от класса window.

мне надо сделать custom_tree_view. тогда я наследуюсь от tree_view, переопределяю конструктор, делаю свою логику, и отдаю из модуля наружу как будто это просто окно. его там куда-то вставляют, оно же окно автоматом и все работает.

тут все красиво потому, что есть наследование и custom_tree_view, это просто окно, ничем не отличающееся от прочих окон.

как это делать в русте? наследования нет.

Ещё раз — ООП это не «член», потому что не является естественной и непременно неотъемлемой частью ЯП. И ты забываешь, что у более чем половины людей члена нет вообще — живут же как-то 😁. Или это нелюди и им надо пришить члены, чтобы с ними было всё ясно и понятно?

тут все красиво потому, что есть наследование

На мой взгляд, в C++11 вот это красивое наследование сломали:

class Foo {
        int w;
public:
        int get_width();
};

int Foo::get_width()
{
        return w;
}

class Bar: Foo {
        int get_width() = delete;
};

int main(int argc, char *argv[])
{
        int w;
        Bar b;
        w = b.get_width(); // error: use of deleted function ‘int Bar::get_width()’
        return 0;
}

Любой софт пишется с прицелом на то что может наследоваться, а что нет. В тех же плюсах в примере с tree_view вам автор покажет, какие функции можно переопределить, воткнув перед ними слово virtual. В расте же эти функции перейдут в трейт, например, TreeViewDatasource или TreeViewDecorator или ещё какой, которые вы и передадите tree_vew. Для второго, декоратора, вам например могут предоставить дефолтную имплементацию, так что он будет опциональным. Ну а сам tree_view реализует трейт Widget поэтому его можно будет вывести на окно.

Наследование - это рак. Никаких проблем оно не решает, кучу создаёт, причём всегда неочевидных.

Ну вот мне нужен. Так что вы со своим «нахрен никому»

Я предлагаю тему ваших специфичных вкусов закрыть.

Это слив.

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

Как раз единственный пример использования чего-то опровергает утверждение «никому не нужен». Так что слив.

Уж извините, что использую вашу терминологию, это вы сюда риторику «слив защитан» притащили.

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

Ну вы сами напросились. Доказываю что вы - балабол на раз-два. Итак, согласно вашим же словам, в Расте нет ООП

Вранье: я не утверждал, что в Расте нет ООП. Я утверждал, что:

нет нормального ООП в Rust-е

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

Также мы помним, что ни трейтов, ни интерфейсов в C++ нет, этот функционал реализуется классами. Следовательно, любое наследование и переопределение в C++ коде, сделанное вами чтоб заимплементить интерфейс, например требуемый API какой-то библиотеки, согласно вашему же определению будет наследованием и переопределением, но не ООП.

С таким бредом к психиатру. Не увидеть интерфейсов в C++, а потом вывести из этого ХЗ когда требовалось просто показать в моем коде (который в достатке в публичном доступе) что наследование и переопределение виртуальных методов – это не ООП… Это нужно было мощный бредогенератор включить.

Вы ставите меня в неудобное положение.

Вы все сами, сами.

ЗЫ. Как говорил выше, требуется время, чтобы поговорить о принципе подстановки по Лисков предметно.

Наследование - это рак.

И структура данных «список» нинужна, ага.

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

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

итак вместо понятия window(у вас это widget) - котрое в соотв. с принципом лисков и было базовым классом, понятием tree_view - которое было реализацией контрола с деревом внутри(которое тоже в соотв с принципов лисков есть window)… то есть у меня есть два понятия .. вы предлагаете что? - widget, tree_view_decorator, tree_view_data_source, tree_view_trait, default_tree_view_trait_impl_as_widget?

код на псевдо-с++

import tree_view;

///класс tree_vew с индентацией элементов - 20
class tree_view_20: public tree_view {
  ///конструктор что создаст окно с индентацией = 20
  tree_view_20() {
    this->set_indent(20);
  }
}

использование:

///в некий book вставляем страницу c таким контролом
some_book_control->add_page(new tree_view_20());

заметим, что в данном коде в синтаксисе псевдо-с++ строго записано следующее формальное высказывание:

«класс tree_view_20 есть tree_view, у которого изаначально установлена индентация 20»

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

Это слив.

Ещё какой. Когда местный эксперт-плюсовик слился по всем фронтам и выпрашивает себе «победу» через «а всё-таки я тебя на неудачном слове поймал», это не просто слив, это позорище.

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

Уж извините, что использую вашу терминологию, это вы сюда риторику «слив защитан» притащили.

Ну а как назвать ваше текущее положение?

Вранье: я не утверждал, что в Расте нет ООП. Я утверждал, что

Ой, как только потребовалось прикрыть свою задницу так сразу ООП в расте неожиданно похорошело.

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

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

И самое интересное, что это вас вообще никак не спасает: ну как ты не тяни сову на глобус, всё равно имплементация интерфейса для библиотечки не может считаться ООП, ну ни в какой вселенной. Это обычная передача ссылки на таблицу с адресами функций, динамическая диспетчеризация как она есть.

С таким бредом к психиатру. Не увидеть интерфейсов в C++

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

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

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

Давайте я вам ещё одну мысль подкину. Вот когда появляется очередной апологет ООП, то первый (и единственный) пример успешного применения ООП, который он приводит, это GUI. Ну вот всё это, типа кнопочка наследуется от виджета и тому подобное. И действительно, это можно описать в терминологии ООП.

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

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

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

ЗЫ. Как говорил выше, требуется время, чтобы поговорить о принципе подстановки по Лисков предметно.

Да конечно, очень сложный и непонятный принцип, сколько там, 2 или даже 3 предложения? Очень много времени надо, чтоб понять, что для любого нетривиального случая принцип Лисковой практически невыполним, ну по крайней мере не стоит результат усилий, и именно поэтому за настоящее ООП на приличном проекте на кодревью по рукам дадут и заставят переписывать до уровня, поддерживаемого растом.

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

Даже более того скажу: все эти трюки не просто можно провернуть, а они и проворачиваются, в том числе и на языках, в которых наследование есть. Как выяснилось, ООП не нужно даже в GUI.

давайте пседокод, а то дискуссия напоминает «базар за жизнь».

Вам ещё надо доказать, что ООП вам нужен.

Мне он нужен.

Как раз чтобы не делать через жопу то, что можно сделать просто и логично на ООП.

Ой, как только потребовалось прикрыть свою задницу так сразу ООП в расте неожиданно похорошело.

Мне не нужно ничего прикрывать. Я отвечаю за слова, которые говорил. А говорил я, что в Rust-е нет нормального ООП.

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

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

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

А это не так.

Очевидно, раз речь об языке Раст, мы говорим о втором понимании.

Под «мы» вы понимаете, вероятно, себя.

Я говорю о том, чего в Rust нет, и что мне нужно, чтобы Rust-вое ООП для меня выглядело нормально.

Во всех учебниках об ООП говорится о 4х столбах, на которых оно стоит: абстракция, инкапсуляция, наследование, полиморфизм.

Смотря каких учебниках.

Изначально говорилось о трех: инкапсуляция, наследование и полиморфизм.

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

Да конечно, очень сложный и непонятный принцип, сколько там, 2 или даже 3 предложения?

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

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

Одно вот это утверждение:

И самое интересное, что это вас вообще никак не спасает: ну как ты не тяни сову на глобус, всё равно имплементация интерфейса для библиотечки не может считаться ООП, ну ни в какой вселенной.

Говорит о вашей полной неадекватности.

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

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

если есть два типа T1 и T2, то нет никакого понимания, кто из них предок или потомок. формально можно считать, что потомком является тот, кто реализует ВСЕ трейты предка. если T1 и T2 реализуют одни и те же трейты - то формально они неразличимы, они не есть ни предок, ни потомок.

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

Если взять как базу для псевдокода iced, то

space(20)

Здесь записано следующее формальное утверждение: «мы создали отступ размером в 20 (который мы потом можем изменить, так же как и в случае с tree_view_20)».

Псевдокод чего? Несуществующей библиотеки? Зачем?

Возьмите реальные библиотеки, например для c#. Или для javascript. Или ту же qt. Везде вас ждёт или датасорс или модель какая-нибудь. Ну тупо неудобно наследовать свой класс грида 5 раз ради того чтоб была возможность запилить грид и для массива элементов и для базы данных.

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

Псевдокод чего? Несуществующей библиотеки? Зачем?

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

мне надо уйти на часок… пока отключаюсь

в расте нет ооп

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

Поэтому какой-то ООП в Rust есть. Как он и есть в чистом Си.

Но в чистом Си этот кастрированный ООП полностью лежит на пользователе и никакой помощи от языка в поддержке ООП нет.

В Rust-е (с моей колокольни) ограниченная поддержка ООП есть на уровне языка (те самые трейты, предоставляющие полиморфизм, но не настолько мощный, как в C++/Java/Eiffel).

Если Rust-оманам этого достаточно, то это же хорошо. Вот серьезно, без подколок.

Другое дело, что тем, кто привык к более продвинутой поддержке ООП прямо в языке уровень Rust-а выглядит бедненько.

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

Какой ещё класс? Тип Space - это инстанс тайп-класса Widget, значение возвращаемое функцией space() имеет тип Space. Значение возвращаемое при вызове space(20) имеет тип Space и начальный установленный размер 20.

Нафига эмулировать классы, если задача (сделать индент 20) выполняется по-другому.

Мне он нужен.

мамой клянётесь?

Доказательства, плз.

Как раз чтобы не делать через жопу то, что можно сделать просто и логично на ООП.

Двойка.

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

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

Отлично, ещё одна тема которую я рылом не вышел обсуждать с ыкспердом.

Я говорю о том, чего в Rust нет, и что мне нужно, чтобы Rust-вое ООП для меня выглядело нормально.

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

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

А, т.е. теперь в Расте ООП стало вполне нормальным, прототипным, а другого как бы и не факт что и надо? «сорян, пацаны, зря быканул»?

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

Вы не заглянули ни в один из первоисточников, но щеки надуваете.

я вам цитату привёл. После которой вы начали валять дурака. И продолжаете до сих пор.

А вот мне интересно почему если базовые определения типа и подтипа упомянуты в работе от 1987-го года, сам принцип считается сформулированным лишь в 1994-ом

И это очередная ложь. Нихрена вам не интересно, было бы интересно, узнали бы об этом в 1996. Или в 2006. Да прямо сейчас, в гугл пока пускают вроде. Вам интересно сейчас только увести беседу от неудобного момента, чтоб казалось будто есть какой-то важный вопрос, который вы непременно хотите узнать. Почему курица пьёт, но не ссыт, ой, простите, почему принцип Лисковой от 94.

Я отвечу вам не глядя в гугл, чисто на основании предположения, выдаваемого здравым смыслом. В 1987, когда народ носился с новой игрушкой и собирался разрушить мир насилья, Барбара Лискова публично обратила внимание на один важный практический момент, но всем было насрать, слишком уж хайповая была тема. «собачка говорит гав» же работает, что ещё надо? В 1994 она опубликовала статью в которой развила ту мысль. А так как к 1994 году ООП уже успело шагнуть в продакшен и многие уже успели набить шишки, статья пришлась в кассу. Примерно тогда вышли паттерны проектирования, которые тоже учили как использовать ООП и не напороться на торчащий гвоздь. Ну а потом люди поняли, что ООП не только не является волшебной пулей, способной бороться с увеличением сложности программ, но и создаёт кучу дополнительных опасностей. Были выработаны правила безопасного ООП, нивелирующие практически все удобства ООП. В рамках этих правил люди работали, во многом по привычке, пилили свои фабрики по созданию фабрик, пока не пришла мода на KISS, YAGNI и прочее аджайл.

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

Как вам такая версия?

в расте нет ооп. то что в расте, можно написать на си.

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

Просто нужен vtable.

Я вас может удивлю, но одним vtable мир ООП не ограничивается.

Понятия наследования, полиморфизма и инкапсуляции ничего не говорят про наличие vtable и прекрасно себя чувствуют для случаев, когда всё ООП остаётся на уровне семантики, доступной компилятору, и не получающей прямого отражения в генерируемом машинном коде.

и не получающей прямого отражения в генерируемом машинном коде

Это когда оптимизатор девиртуализирует вызовы виртуальных функций используя статический анализ кода? Вообще-то constant propagation, частным случаем которой является девиртуализация, очень слабо связана с ООП.

Нет.

те самые трейты, предоставляющие полиморфизм, но не настолько мощный, как в C++/Java/Eiffel

В расте, если я все правильно понимаю, всё нормально с динамическим полиморфизмом:

fn dynamic_dispatch(p: &dyn Printer) {
    p.print();
}

по-моему, ничем принципиально не отличается от виртуальных методов С++, ТВМы устроены немного по-другому, синтаксис другой, ну а по сути тоже самое.

Поэтому какой-то ООП в Rust есть.

Да самый настоящий ООП. Непривычный просто. Наследование? В расте есть более мощная штука, можно имплементировать дефолтное поведение для трейта, и специфицировать дефолт для конкретной реализации, в принципе тоже наследование

struct Point {
    x: i32,
    y: i32
}

struct Square {
    left_up: Point,
    right_bottom: Point
}
struct Triangle {
    a: Point,
    b: Point,
    c: Point,
}

fn distance(a: &Point, b: &Point) -> f64 {
    (((a.x - b.x ).pow(2) + (a.y - b.y).pow(2)) as f64).sqrt()
}

trait Polygon {
    fn get_lines(&self) -> Vec<(Point, Point)>;
    fn perimetr(&self) -> f64 {
        self.get_lines().into_iter().map(|l| distance(&l.0, &l.1)).sum()
    }

}

impl Polygon for Square {
    fn get_lines(&self) -> Vec<(Point, Point)> {
        ...
    }
}

impl Polygon for Triangle {
    fn get_lines(&self) -> Vec<(Point, Point)> {
        ...
    }
}

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

Блин, я думал вы от меня требуете примера с датасорсом/моделью, даже нашёл ссылку на туториал в QT5, а вам отступы подавай.

В общем ваш псевдокод - говно. Зачем пилить наследника вся задача которого состоит в определении нового дефолтного значения для существующей уже поддерживаемой проперти?

Но, если вам так хочется, аналог вашего псевдокода будет примерно таким:

trait WithIndent {
    fn withIndent(i: i32) -> self;
}

impl WithIndent for TreeView {
    fn withIndent(i: i32) -> self {
        let r = TreeView::new();
        r.setIndent(i);
        r
    }
}
fn main() {
  //...
  let indented = TreeView::withIndent(32);
}

Подождал 10 минут, но никаких разъяснений не появилось. Не томите. Что это за семантика ООП такая, которая не находит отражения в скомпилированном коде?

Если что, принцип Лисков - это просто соглашение, которое программисты не обязаны соблюдать. Так что и тут не обойтись без статического анализа кода, который проверит, что этот принцип выполняется (точнее какая-то формализация этого принципа, который сам по себе довольно расплывчат).

В расте, если я все правильно понимаю, всё нормально с динамическим полиморфизмом:

Пример был приведен выше. Обратите внимание на вызов виртуального cleanup.

Кроме того, есть ли в Rust наследование traits? Типа generic_io_device с наследниками serial_io_device и block_io_device. И чтобы от block_io_device можно было еще наследников сделать, типа dummy_block_io_device. И чтобы экземпляр dummy_block_io_device можно было отдать и в функцию, принимающую block_io_device, и в функцию, принимающую generic_io_device.

вот это уже деловой разговор!

теперь несколько меняем искомый класс

///класс tree_vew которому задают индент по умочанию и тут же его ///ставят. индент по умолчанию нельзя изменить снаружи этого класса.

class tree_view__: public tree_view {
  int _default_indent = 10;
public:  
  tree_view__(int default_indent) {
    this->_default_indent = default_indent;
    this->set_indent(_default_indent);
  }
}

использование:

///в некий book вставляем страницу c таким контролом, у которого индент по умолчанию - 30
some_book_control->add_page(new tree_view__(30));

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

В найтли можно без дополнительных приседаний: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1427af1d9086a505ca2cb8e062d25ac2

Для стейбла нужно раскомментировать код.

мамой клянётесь?

Я же не вы, у меня код есть.

Существует класс agent_t, который не абстрактный виртуальный, а просто класс с рядом виртуальных методов. Например: so_define_agent, so_evt_start, so_evt_finish, so_exception_reaction и др.

Это не чисто абстрактные методы. Они определены. Кто-то как пустышка, кто-то делает дефолтные действия.

Пользователю нужно отнаследоваться от agent_t. И, если он хочет что-то поменять в логике по умолчанию, он переопределяет один из виртуальных методов. Например, нужно сделать что-то на старте – переопределяется so_evt_start. Нужно сделать что-то на финише – переопределяется so_evt_finish. Если не нужно, то не переопределяется.

Далее открывается возможность делать семейства агентов под задачу. Какой-то класс basic_data_listener, который переопределяет so_define_agent. Если наследникам basic_data_listener нужно что-то дополнительное, они переопределят so_define_agent (или любой другой метод) у себя. При этом сам фреймворк как видел agent_t, так и видит.

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

Доказательства, плз.

Хотелось бы попросить такого же поведения и от вас, но вы же известный здесь khrundel, так что это заранее бесполезно.

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

В интернетах много чего пишут. Вы тут целые простыни высрали.

Только вот звездуны вроде вас не производят код.

Отлично, ещё одна тема которую я рылом не вышел обсуждать с ыкспердом.

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

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

Во-первых, перечитайте то, что я писал.

Во-вторых, не приписывайте собеседнику то, что он не говорил.

А, т.е. теперь в Расте ООП стало вполне нормальным, прототипным, а другого как бы и не факт что и надо?

Во-первых, не стало.

Во-вторых, оно там и не прототипное.

И это очередная ложь

Вы еще расскажите здесь что у меня в голове. Ну или попробуйте диагнозы по Интернету поставить. У вас получится.

Пользователю нужно отнаследоваться

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

В расте это может выглядеть как .subscribe_evt_start(impl FnMut(...)).

Да, для гуя в статически-типизированных языках, ООП оказалось довольно удачной парадигмой. Хотя, судя по популярности web-gui, можно быть и удачнее.

Пользователю (библиотеки) нужно решить какую-то задачу.

Да. Поэтому берут библиотеку, написанную в ООП стиле и не парят себе мозх.

В расте это может выглядеть как .subscribe_evt_start(impl FnMut(…)).

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

Кто хочет так долбаться под хвост – нет проблем.

Просто про «ООП говно» трындеть не нужно.

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

Не только для GUI, но доказывать никому ничего не собираюсь.

Хотя не могу не позлорадствовать тому, что ООП для Rust-а был так ненужен, ну так ненужен, что хотя бы вот это вот в язык стали запихивать спустя 8 лет. Тогда как в ООП языках (или мультипарадигменных, но с приличной поддержкой ООП) это сразу из коробки.

Если вернуться к основной теме форума, то ядро линукса как-то живёт без явного наследования. Идиоты, наверно, 30 лет «долбаться под хвост».

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

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

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

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