Наследование в Rust

Как C справляется с иерархией виджетов gtk?

Крайне х%во.Почитай, например:

http://www.cc.gatech.edu/data_files/public/doc/gtk/tutorial/gtk_tut-20.html

Это ад на Земле.

Про какую литературу речь, например?

Rust создавался как язык для реализации движка Servo. Как мне кажется, в реализации браузерного движка полно ООП концепций. Наверное как-то справляется Rust?

Rust создавался как язык для реализации движка Servo

Это, конечно, чушь.

В rust более чистый и ясный подход. Не надо ОО-грязь в язык тащить без оснований. Есть trait'ы, есть impl'ы, есть конкретные типы. Все ортогонально и прозрачно. Плюс trait'ы используются и для статических ограничений для параметров дженерика. Возможно, стоит добавить миксины. Возможно, стоит ввести механизм делегирования impl'а.

в реализации браузерного движка полно ООП концепций

Такая же мысль пришла, хорошо гитхаб под боком, сразу можно посмотреть, как они ООП пытаются костылять на HTMLElement'ах https://github.com/servo/servo/blob/09f2977cc945850a35f7a5ef1ed014bc42cb265a/...

impl<'a> VirtualMethods for JSRef<'a, HTMLAnchorElement> {
    fn super_type<'b>(&'b self) -> Option<&'b VirtualMethods> {
        let htmlelement: &JSRef<HTMLElement> = HTMLElementCast::from_borrowed_ref(self);
        Some(htmlelement as &VirtualMethods)
    }

    fn handle_event(&self, event: JSRef<Event>) {
        match self.super_type() {
            Some(s) => {
                s.handle_event(event);
            }
            None => {}
        }
    }

    fn parse_plain_attribute(&self, name: &Atom, value: DOMString) -> AttrValue {
        match name {
            &atom!("rel") => AttrValue::from_serialized_tokenlist(value),
            _ => self.super_type().unwrap().parse_plain_attribute(name, value),
        }
    }
}

impl<'a> HTMLAnchorElementMethods for JSRef<'a, HTMLAnchorElement> {
    fn Text(self) -> DOMString {
        let node: JSRef<Node> = NodeCast::from_ref(self);
        node.GetTextContent().unwrap()
    }

    fn SetText(self, value: DOMString) {
        let node: JSRef<Node> = NodeCast::from_ref(self);
        node.SetTextContent(Some(value))
    }

    fn RelList(self) -> Temporary<DOMTokenList> {
        self.rel_list.or_init(|| {
            DOMTokenList::new(ElementCast::from_ref(self), &atom!("rel"))
        })
    }
}

В rust более чистый и ясный подход

Неужели? А почему в такой стандартной ООП ситуации городят такие костыли:

https://github.com/servo/servo/blob/09f2977cc945850a35f7a5ef1ed014bc42cb265a/...

Т.е. теперь каждый программер, напилит своих методов new_inherited, super_type и т.д. А потом, сиди, ипи моск, разбирайся как он тут замутили свою ООП имитацию?

Такая ситуация очень похоже на JS, где +100500 эмуляций ООП. Но в конце-концов ES6 поправят, сделали, нормальные классы.

А почему в такой стандартной ООП ситуации городят такие костыли:

Может потому, что DOM это чисто классическая ООП структура? В нормальном ржавом коде (равно как и в хаскельном или идеоматичном скалистом) просто не должно быть таких проблем, ибо архитектура строится иначе.

Т.е. теперь каждый программер, напилит своих методов new_inherited, super_type и т.д.

Дык, если это кодер из крестов или жабы, то да, напилит. Хороший разработчик же должен просто принять, что в ЯПе используется другая парадигма и осилить уже, наконец, АлгТД и тайпклассы, а не тащить в язык инородные предметы. Как известно, «программист на Фортране может написать программу на Фортране на любом языке программирования» ©.

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

А почему в такой стандартной ООП ситуации городят такие костыли

Потому, что большинство программистов - тупые.

осилить уже, наконец, АлгТД и тайпклассы, а не тащить в язык инородные предметы

Ок'ей, т.е. HTML инородный предмет?

то вполне эмулировать наследование реализаций можно через реализацию трейта Deref

А как же илитный раст код и инородный предмет?

просто принять, что в ЯПе используется другая парадигма

А может стоит принять, что в этом мире, некоторые вещи удобнее делать через ООП?

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

Слушайте, а зачем, вы тогда объявляете его как замена крестам? Вы ведь отнимаете, время у практиков. Для, которых HTML это не инородный предмет.

Ну сказали бы, что у вас илитный ЯП, сидели бы спокойно в своем илитном идеоматичном кружке. И никто бы вас не трогал.

Но так нет, замена крестам же! И отрываете этим добрых людей, от отдыха, личных дел, от работы над реальными задачами...

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

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

https://ru.wikipedia.org/wiki/Спор#.D0.93.D1.80.D1.83.D0.B1.D0.B5.D0.B9.D1.88...

Это действительно не аргумент. Но ты бы лучше и правда со своими запятыми разобрался. Читать неприятно.

Я ни в коем разе не хотел обижать тебя, незнакомец. Просто читать не очень удобно. Да и спор с тобой я не затевал.

А, ну ладно ) Я просто не разобрался как тут редактировать сообщения. А удалять и снова добавлять - лень )

А может стоит принять, что в этом мире, некоторые вещи удобнее делать через ООП?

Как только в rust 2.0 добавят ООП, его фанаты начнут думать аналогично. А пока поддержки ООП нет - он и не нужен вообще, другие подходы лучше и все такое.

Ок'ей, т.е. HTML инородный предмет?

Для тайпклассов вполне.

А может стоит принять, что в этом мире, некоторые вещи удобнее делать через ООП?

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

И отрываете этим добрых людей, от отдыха, личных дел, от работы над реальными задачами...

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

Вы ведь отнимаете, время у практиков.

Именно. Это то, что, возможно, убьёт rust.

Как только в rust 2.0 добавят ООП, его фанаты начнут думать аналогично. А пока поддержки ООП нет - он и не нужен вообще, другие подходы лучше и все такое.

Как только в C++100500 добавят концепты, его фанаты начнут думать аналогично. А пока нет поддержки концептов - он и не нужен вообще, другие подходы лучше и все такое.

Такая ситуация очень похоже на JS, где +100500 эмуляций ООП. Но в конце-концов ES6 поправят, сделали, нормальные классы.

Ну да. Ведь

Потому, что большинство программистов - тупые.

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

P.S. хватит называть «ООП» только классовую модель. Да и вообще этот термин лучше не использовать, ибо сегодня под ним понимают что угодно (и совсем не то же самое, что понимали Хоар, Алан Кей, Кристофер Стретчи и другие современники).

P.P.S забей на эти упрёки на тему запятых. Нашлись тут граммар-наци, ага.

Концепты нужны. Реализации есть (boost, gcc libstdc++) и активно используются. Но впихнуть нормальные концепты в язык и библиотеку, без перелопачивания всего на своём пути, очень сложно. Поэтому только в C++17 их может быть и сделают.

Вот такое вот, блин, там «ООП».

Всё в ручную, как в Си.

Разумеется нужны, да. А лучше сразу тайпклассы. Только вот пока перепишут стандартную либу, пока появится пласт библиотек, построенных с концептами — сто лет пройдёт. Большинство крестового кода застряло на уровне 98-го года, а мы тут про концепты.

активно используются

Реквестую пример.

Но ведь пользователи C++ так не думают. Концепты нужны.

разве GUI - это не как раз самый сильный довод и пример использования наследования классов ?

Как раз это яркий пример бесполезности концепции.