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

struct MyFancyTreeView {
  parent_tree_view: TreeView,
  default_indent: i32
}

#[redirect(parent_tree_view, setIndent, getIndent, render, preRender, ... )]
impl TreeViewTrait for MyFancyTreeView
{
  fn resetIndent(&mut self) {
    self.parent_tree_view.setIndent(self.default_indent)
  }
}

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

это единственный «пример» что я нашел. ну давайте на него смотреть.

первое что пугает - цитирую

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

пугает упоминание о «несуществующем макросе, который верятно(!!!) можно написать».

паслушьте. совсем не интересно, что там у вас в расте не существует, и что ВЕРОЯТНО (но не точно! гы) можно написать. интересуют стандартные механизмы языка, а не «несуществующие макросы».

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

да и что мы видим из этой записи?

есть левая структура куда включен TreeView. типа ого-го «наследование».

и есть имплементация трейта TreeViewTrait (у которого с пару сотен методов) с одной всего функцией. то есть теперь эта имплементация с одним методом стала совместима со всеми, кто реализует пару сотен?

кого отдавать вообще ГУЮ в качестве кастомного окна тут? чтобы вставить в какой-нить book.

короче непонятно.

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

И всё это называется - прогресс.

я вот пока не понял, а каким способом новая структура стала удовлетворять трейту TreeViewTrait? надо пойти почитать

Где-то я такое видел. И иногда такое нужно, но вот всегда и везде использовать композицию это какой-то тупняк и антипаттерн.

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

тему он откровенно забалтывает.

Если позволите, напомню тему:

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

🤣🤣🤣

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

khrundel ★★★★ (02:41:42 Ср 22/11/2023) отныне мой любимый герой Development 😊

это единственный «пример» что я нашел. ну давайте на него смотреть.

Скажите, а вас не смутило вводное слово «чисто поржать»? Нет, конечно, не тот пример.

Напоминаю краткое содержание предыдущих серий.

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

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

• не даёт особого выигрыша в количестве кода по сравнению с декоратором
• делает код наследника хрупким

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

пугает упоминание о «несуществующем макросе, который верятно(!!!) можно написать».

Ну извините, я макросы для раста не писал, не знаю точно какие там есть возможности. Во встроенной библиотеке уже есть макрос derive, который, например, позволяет написать перед структурой #[derive(Debug)] и внезапно компилятор сгенерирует для данной структуры реализацию трейта Debug, форматирующую в текст все поля данной структуры. И ещё другие трейты можно реализовать автоматически с помощью derive, например библиотека сериализации serde создаёт необходимые методы для произвольных типов именно через #[derive(Serialize, Deserialize)], где Serialize и Deserialize - это трейты библиотеки. Так что подход выбранный растом ясен, и такая «рефлексия» на этапе кампиляции в теории могла бы реализовывать трейты через переадресацию методов выбранному полю, реализующему этот же трейт. «Вероятно» и «в теории» от того что я просто не знаю, может ли макрос получить, например, информацию о методах в трейте, чтоб сгенерировать код переадресации правильно.

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

и есть имплементация трейта TreeViewTrait (у которого с пару сотен методов) с одной всего функцией. то есть теперь эта имплементация с одним методом стала совместима со всеми, кто реализует пару сотен?

В виду общего слабоумия вы заслуживаете права на скидку, поэтому поясню: безусловно, никакой трейт не должен содержать пары сотен методов. Однако количество методов не важно. Важно то, что программист при таком подходе сам перечислит методы, которые он предлагает переадресовать члену, чтоб если впоследствии в трейте появятся новые методы, как например появится в нашем «базовом» трейте Widget появится поддержка баблинга мышинных евентов или появится новый бекенд, кроме drawUsingCairo появится метод drawUsingShmairo, чтоб компилятор молча(!) не взял метод базового класса, который для дочернего уже может быть некорректным. В общем если в трейте 100 методов - в моём гипотетическом макросе придётся перечислить все 100. И не потому что «гыгы, раст плохой не умеет», нет, для макроса переадресации всех методов (который был бы аналогом наследования) нужны ровно те же возможности что и для переадресации указанных методов, перечисление необходимо чтоб спастись от одного из косяков самого наследования.

вот вам руст стайл на с++

///printer interface
struct i_printer {
	virtual void print() = 0;
};

///scanner interface
struct i_scanner {
	virtual void scan() = 0;
};

///printer+scanner interface
struct i_printer_scanner:	
	i_printer, 	
	i_scanner
{
};

///some concrete HP device driver
struct The_device_driver_HP {
	void hw_print(){}
	void hw_scan(){}
};

///implementation of i_printer_scanner using concrete device driver
struct PrinterScanner:
	i_printer_scanner
{
	The_device_driver_HP _driver;  ///compose
	void print() override {	_driver.hw_print(); };
	void scan() override {	_driver.hw_scan(); };
};

///printer + scanner object
i_printer_scanner* printer_scanner = new PrinterScanner;

///printing only
i_printer* printer = printer_scanner;

///scanning only
i_scanner* scanner = printer_scanner;

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

Хрюндель продолжает отжигать. Эксперт уровня ЛОР. Жму лапу!

И чего тут растового? То что классы названы struct?

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

PrinterScanner и i_printer_scanner лежат себе в заголовках, практически нет никаких функций в заголовке, чтоб читатель читал. _driver может вообще указателем быть, чтоб pimpl и чтоб заголовок очистить.

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

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

О, чувствуются слова не мальчика, но enterprise architect-а.

Может вы в этом коде еще и какие-то гарантии соблюдения принципа подстановки Лисков видите?

И чего тут растового? То что классы названы struct?

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

просто соединю две цитаты в одну, получится - «что ж тут растового, это типичный high quality, SOLID дизайн».

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

вот потому-то с++ и является эффективным языком для разработки софта.

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

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

А что значит «язык 1-го класса в своих инженерных системах»?

Фу, раст. Нинужно. Есть zig.

Скорее всего, это перевод надмозга вместо «первоклассного языка», т.е. образцовый язык.

Похоже на отсылку к идиоме «1st class citizen» - «полноправный гражданин». Короче, чтоб раст можно было использовать везде в этих системах.

Если бы многие поклонники этого языка не вели себя как свидетели Иеговы

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

Lesbian

Это какой то клон Debian?

Раст для чушпанов.

Предложи альтернативу ООП для большого и сложного софта. Костылить недоООП самому, как гномеры?

очевидное ФП очевидно. Как пример - tezos - большой и сложный, на Окамле стиле чистого фп (без ооп).