Здравствуйте, Michael7, Вы писали:

M>Здравствуйте, Doom100500, Вы писали:


M>>>Я в основном про GUI виндов. Если бы CreateFile отправлял сообщения это уже какой-то совсем SmallTalk был бы.

D>>

D>> WIN API — это не только GUI. А GUI — это обмен сообщениями везде — не только в WINAPI.

D>>А причём тут WINAPI?

M>Что-то это как придирки уже выглядит. API виндов — это WinAPI по определению. И довольно очевидно, что их разработчики (Ok, GUI подмножества) явно имели ввиду концепцию обмена сообщениями. Вот и все о чем речь. Знали ли они про SmallTalk тоже интересный вопрос, в принципе весьма вероятно, что знали.

Это не придирки. Изначальное утверждение, что весь WIN API проектировался как event-driven — в корне не верное и вводит в заблуждение.

А UI — везде event-driven бес связи частью чего он является.
UI на js — это event loop, и кWIN API отношения не имеет.

Здравствуйте, so5team, Вы писали:

S>>>Из-за чего она возникла -- ошибки в дизайне или отшибки в ДНК спорящих на RSDN -- вообще не важно.
BFE>>Да, причина не важна. Хотелось бы другого — понять в чём, собственно, проблема.
S>А что вам не понято в исходном примере?
Не понятно причём тут ООП. Проблема совпадения по именам шире чем ООП и в том же C встречается довольно часто.

Здравствуйте, so5team, Вы писали:

S>struc D : public A, public B
S>{
S> void f() override A::f {
S> std::cout << "D's f from A" << std::endl;
S> A::f();
S> }
S> void f() override B::f {
S> std::cout << "D's f from B" << std::endl;
S> B::f();
S> }
S>};

А что должно делать

D d;
d.f()?

Здравствуйте, B0FEE664, Вы писали:

BFE>Не понятно причём тут ООП.

https://rsdn.org/forum/flame.comp/8985488.1

Автор: so5team
Дата: 01.09 14:21

Здравствуйте, T4r4sB, Вы писали:

TB>А что должно делать

TB>

TB>D d;
TB>d.f()?

Выдавать ошибку о том, что вызов неоднозначен.
Либо, если требуемая функциональность реализуется посредством переименования методов в D (как это делается в Eiffel), говорить о том, что f для D нет. Если же переименован только один из двух f(), то в случае d.f() должен вызываться тот, что остался со старым именем.

Здравствуйте, so5team, Вы писали:

S>Выдавать ошибку о том, что вызов неоднозначен.
S>Либо, если требуемая функциональность реализуется посредством переименования методов в D (как это делается в Eiffel), говорить о том, что f для D нет.

То есть, f есть для A и для B, но её нет для D. То есть, D не является ни A, ни B. Но при этом почему-то используется наследование. И почему мы на ошибке дизайна обсуждаем проблемы ООП в C++?

Пардон, я опять запутался, что мы обсуждаем.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, T4r4sB, Вы писали:

TB>>А что должно делать

TB>>

TB>>D d;
TB>>d.f()?

S>Выдавать ошибку о том, что вызов неоднозначен.

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

Здравствуйте, rg45, Вы писали:

S>>Либо, если требуемая функциональность реализуется посредством переименования методов в D (как это делается в Eiffel), говорить о том, что f для D нет.

R>То есть, f есть для A и для B, но её нет для D. То есть, D не является ни A, ни B.

Является.

R>Но при этом почему-то используется наследование.

Потому что может.

Например, емнип, в Qt вы не можете сделать Widget, который не является наследником Qt-шного класса (вроде бы QWidget).
В ACE, емнип, вы не можете сделать обработчика событий для ACE_Reactor не отнаследовавшись от ACE_Event_Handler.
И если кому-то вдруг потребуется сделать Widget, который одновременно будет и Event_Handler-ом для ACE, то одним из самых простых способов будет отнаследоваться и от QWidget, и от ACE_Event_Handler.

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

R>И почему мы на ошибке дизайна обсуждаем проблемы ООП в C++?

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

Я пытаюсь иронизировать над "настоящим ООП" вообще и конкретно над "настоящий ООП только в SmallTalk".

Уж простите мне, что я использовал в своем примере синтаксис C++.
Надо было синаксис Java взять.

R>Пардон, я опять запутался, что мы обсуждаем.

За пределами C++ тоже есть интересная жизнь. Кто-то может считать, что настоящий ООП только в SmallTalk. А кто-то, причем с (почти) теми же самыми аргументами -- что Erlang.

Здравствуйте, T4r4sB, Вы писали:

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

Да.

TB>Просто совпало имя и сигнатура.

Да.

TB>Это может вообще досадная мешающая случайность как бы.

Да.

TB>Тогда присоединяюсь к утверждению что это проблема совпадающих имен.

Пофиг как называется. Важно есть ли в языке инструменты для ее решения.

TB>А вот в Расте кажется можно

Можно узнать как? Без сарказма, реально интересно.

Здравствуйте, Muxa, Вы писали:

M>Ииии?
M>Задачи-то какие таким подходом проще решать?

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

Например, всё сетевое работает с любой хренью, которая реализует интерфейс net.Conn. И этот самый Conn — совершенно не обязательно сетевой сокет. И при этом, скажем, библиотечная реализация http клиента или сервера может вообще ничего не знать про богатую внутреннюю жизнь того, что она считает сетевыми соединениями, лишь бы интерфейс соблюдался.

Теоретически, можно это сравнить с виртуальными классами C++. Но в Go конкретные типы, реализующие интерфейсы, не наследуют от этих интерфейсов, а просто реализуют их. Поэтому не возникает зависимости, нет необходимости как-то импортировать определение "базового класса" и т.п. Нет вот этого, как в C++, что даже если два разных определения одного и того же интерфейса в точности совпадают, то это всё равно два разных типа, и поди скрести их в одном наследнике.

Здравствуйте, Doom100500, Вы писали:

M>>Интересно, что WinAPI явно проектировали под сильным влиянием идеи классов, обменивающихся сообщениями.

D>Это про что?

D>CreateFile — какое сообщение и кому отправляет? Где ловят ответ на это сообщение? WIN API — это не только GUI. А GUI — это обмен сообщениями везде — не только в WINAPI.

Наверное, речь про оконно-графический API.

Но он вообще во всех оконках примерно такой.

Здравствуйте, Michael7, Вы писали:

M>Что-то это как придирки уже выглядит. API виндов — это WinAPI по определению. И довольно очевидно, что их разработчики (Ok, GUI подмножества) явно имели ввиду концепцию обмена сообщениями. Вот и все о чем речь. Знали ли они про SmallTalk тоже интересный вопрос, в принципе весьма вероятно, что знали.

SmallTalk пришел из Xerox и GUI, как мы его знаем, тоже пришел из Xerox. Я думаю, там есть прямое влияние идей. Не просто случайное совпадение.

Здравствуйте, so5team, Вы писали:

S>Можно узнать как? Без сарказма, реально интересно.

В расте можно написать просто метод для класса, а можно написать метод для класса для реализации интерфейса.
То есть если есть

trait Fooble {
  fn foo(&self) {
    println!("default Fooble::foo");
  }
}

И просто структура

struct S {}

impl S {
  fn foo(&self) {
    println!("S::foo");
  }
}

То это ты просто написал метод класса не имеющий отношения к интерфейсу. И если в коде есть

fn make_foo(f: &impl Fooble) { ...

То эту свою S туда не подсунешь
Но если ты прямо сказал что не просто пишешь foo а именно реализуешь метод интерфейса то можно так:

impl Fooble for S {
  fn foo(&self) {
    println!("S::foo");
  }
}

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

impl Fooble1 for S {
  fn foo(&self) {
    println!("S::foo for Fooble1");
  }
}

impl Fooble2 for S {
  fn foo(&self) {
    println!("S::foo for Fooble2");
  }
}

Заметь что при объявлении структуры я нигде не пишу каким интерфейсам она соответствует. Ты можешь вообще придумать свой интерфейс и написать реализацию любого типа (даже i32) для этого интерфейса. И этот интерфейс можно будет использовать динамически! При этом i32 это по-прежнему 32-битное число без лишних полей с vtbl_ptr которое в структурах и массивах хранится плотно без лишних байтов

Здравствуйте, B0FEE664, Вы писали:

BFE>2. Настоящий ООП был придуман для симуляции поведения живых существ, а не роботов. Очень редко кому нужна такая симуляция. Практически никто не ожидает, что, к примеру, кнопка [OK] заболела, покрылась плесенью и поэтому отправить документ на печать сегодня невозможно.

А зря не ожидают.

Вот потому кнопку [OK] никто и не лечит, что не ожидают, что она может заболеть. А она может.

Здравствуйте, rg45, Вы писали:

S>>Недоучки по настоящему ООП не освоили (из-за Basic и С++)

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

Эта тема полностью раскрыта в советских мультихах про Незнайку

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, so5team, Вы писали:

S>>Можно узнать как? Без сарказма, реально интересно.

TB>В расте можно написать просто метод для класса, а можно написать метод для класса для реализации интерфейса.

Спасибо, так уж подробно не надо было.

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

trait AIface {
  fn f(&self);
}

struct A {...}

impl AIface for A {
  fn f(&self) {...}
}

trait BIface {
  fn f(&self);
}

struct B {...}

impl BIface for B {
  fn f(&self) {...}
}

struct D {
  // Нет наследования, поэтому агрегируем.
  _a: A,
  _b: B
}

impl AIface for D {
  fn f(&self) {
    _a.f();
    ...
  }
}

impl BIface for D {
  fn f(&self) {
    _b.f();
    ...
  }
}

Здравствуйте, so5team, Вы писали:

S>Я правильно понимаю, что с учетом отсутствия наследования в Rust-е, показанный мной пример выглядел бы как-то так (прошу прощения за косяки с синтаксисом):

Ну да, чето такое

Здравствуйте, so5team, Вы писали:

S>Нет. Я показываю проблему, когда в базовых классах имена совпадают. А в производном нужно как-то сделать выбор чтобы явно указать какой именно метод переопределяется.
То есть переименовать метод в иерархии классов — это такая реальная проблема ООП языка? Вот это вы серьёзно сейчас?

Здравствуйте, rg45, Вы писали:

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

Вот сейчас было реально обидно

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

Хотя тема не моя, я просто принес ссылку и скопировал цитату автора:

Да, я уже выше сказал это. Главным был переход на ООП. С которым «недоучки» не торопились и я уверен до сих пор по настоящему ООП не освоили до сих пор. Именно из‑за Бэйсика. И С++.

— немного урезал.

Здравствуйте, B0FEE664, Вы писали:

S>>Нет. Я показываю проблему, когда в базовых классах имена совпадают. А в производном нужно как-то сделать выбор чтобы явно указать какой именно метод переопределяется.
BFE>То есть переименовать метод в иерархии классов — это такая реальная проблема ООП языка? Вот это вы серьёзно сейчас?

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