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

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

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

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

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

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

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

S>Дал бы Шмыга определение Ъ-шности, было бы проще. Но Шмыга как обычно Шмыга.
S>Поэтому можно озвучить вот такой критерий.

вот например определение от ИИ:

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

Так как это скорее всего компиляция из многих источников, то можно сказать что наиболее широко распространённое определение.
Никакого множественного наследования, никаких сигналов из smalltalk.

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

S>Что до желания обсудить настоящесть ООП, предлагаю рассмотреть реализацию такого примера (псевдокод в синтаксисе a la C++, но на C++ это не реализуется):

С адаптером можно:

#include <iostream>

struct A
{ virtual void f() { std::cout << "A::f" << std::endl; } };

struct B
{ virtual void f() { std::cout << "B::f" << std::endl; } };

void consume_A(A & o) { o.f(); }
void consume_B(B & o) { o.f(); }

struct A_side : A
{
    void f() override
    {
        std::cout << "D's f from A\n";
        A::f();
    }
};

struct B_side : B
{
    void f() override
    {
        std::cout << "D's f from B\n";
        B::f();
    }
};

struct C : A_side, B_side
{};

int main()
{
    C c;
    consume_A(c);
    consume_B(c);
}

D's f from A
A::f
D's f from B
B::f

Я не ради спора с вашим определением "ООП-чистого языка", а к тому, что желаемый практический эффект достигается имеющимися средствами.

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

SP>вот например определение от ИИ:

SP>

SP>Объектно-ориентированное программирование — это парадигма программирования, в которой основными строительными блоками являются объекты, представляющие собой экземпляры классов, объединяющие в себе состояние (данные) и поведение (методы). ООП направлено на моделирование реального мира через абстракции, обеспечивая гибкость, масштабируемость и повторное использование кода.

SP>Так как это скорее всего компиляция из многих источников, то можно сказать что наиболее широко распространённое определение.
SP>Никакого множественного наследования, никаких сигналов из smalltalk.

Определение ООП без "наследования, инкапсуляции и полиморфизма" (хотя бы)?

Не, не пойдет.

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

S>Я не ради спора с вашим определением "ООП-чистого языка", а к тому, что желаемый практический эффект достигается имеющимися средствами.

Прекрасно и что?

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

R>>И я бы не сказал, что это какая-то широкораспространённая проблема, которая создаёт массовые неудобства.

S>Речь не про проблему, а про определения и следование этим определениям.

А из какого определения (ООП или полиморфизма) следует, что вызовы consume_a и consume_b обязаны дать разные результаты? Что мешает реализовать D::f, например, вот так:

http://coliru.stacked-crooked.com/a/fe324739d29727b0

struct D : A, B
{
  void f() override {
    A::f();
    B::f();
    std::cout << "D::f" << std::endl;
  }
};

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

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

S>>Речь не про проблему, а про определения и следование этим определениям.

R>А из какого определения (ООП или полиморфизма) следует, что полиморфное поведение должно быть реализовано только так, как показано у тебя в примере, а не, например, как в примере ниже?

R>Как по-мне, то это просто частный случай, а не нарушение каких-то общих требований.

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

Вот в стартовом сообщении было сказано "настоящий ООП — был только в Smalltalk".
Попробуем посмотреть на это утверждение с позиции решения конкретной проблемы (мой исходный пример).
Эта проблема в SmallTalk не решается, хотя, казалось бы, мы же исключительно в рамках ООП находимся.
Т.е. типа "настоящий ООП" из SmallTalk-а не может помочь в чисто ООП-ной парадигме.

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

class
  D
inherit
  A
    rename
      f as f_A
    end
  B
    rename
      f as f_B
    end
feature
  f_A
    do
      ...
    end
  f_B
    do
      ...
    end
end

При этом Eiffel, поскольку он не SmallTalk, а "настоящий ООП только в SmallTalk" -- значит настоящим ОО-языком типа быть не должен.
Зато эту самую проблему он решает искаропочными средствами без привлечения каких-либо промежуточных костылей.

Следовательно, к "настоящему ООП" из SmallTalk-а есть вопросики.

Но, блин, C++ники, сломя голову бросились защищать C++, типа "ну как же на нем такого не сделать, ну вот же ж у меня же ж..."
Тьфу, срамота.

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

S>Вот в стартовом сообщении было сказано "настоящий ООП — был только в Smalltalk".
S>Попробуем посмотреть на это утверждение с позиции решения конкретной проблемы (мой исходный пример).
S>Эта проблема в SmallTalk не решается, хотя, казалось бы, мы же исключительно в рамках ООП находимся.
S>Т.е. типа "настоящий ООП" из SmallTalk-а не может помочь в чисто ООП-ной парадигме.

S>При этом Eiffel, поскольку он не SmallTalk, а "настоящий ООП только в SmallTalk" -- значит настоящим ОО-языком типа быть не должен.
S>Это эту самую проблему он решает искаропочными средствами без привлечения каких-либо промежуточных костылей.

S>Следовательно, к "настоящему ООП" из SmallTalk-а есть вопросики.

S>Но, блин, C++ники, сломя голову бросились защищать C++, типа "ну как же на нем такого не сделать, ну вот же ж у меня же ж..."
S>Тьфу, срамота.

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

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

R>Ну чего ты кипятишься?

Вот только диагнозы через Интернет не надо ставить.

R>Ты заложил в свое сообщение неявную цепочку рассуждений, слишком сложную для среднего ума

C++ники решили, что они могут позволит себе нарушать условия задачи. Кто-то non-virtual-public-interface решил использовать, кто-то дополнительные сущности. А низзя!

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

S>>>Предлагаю посмотреть на свой код, на исходный и сравнить сигнатуры виртуальных методов f и vf. В исходном примере сигнатуры одинаковые, в вашем -- нет.
BFE>>Сигнатуры f одинаковые.
S>f в вашем примере не виртуальная функция. Т.е. это не эквивалент ни разу.
Так в этом и состоит "ошибка" исходного примера: если потомок не должен наследовать поведение, то функция не должна быть виртуальной.

S>Ваш пример показывает то, что если в языке напрямую нельзя сделать требуемое, то можно найти обходной маневр, усложнить логику и обложиться обертками. Но все это лишь демонстрирует недостаточный уровень поддержки ООП из-за чего обходной маневр с обертками и нужен.
Не согласен. Приведённый пример может демонстрировать три различных проблемы:
1) ошибка в дизайне иерархии: метод который не должен наследоваться объявлен виртуальным;
2) ошибка в дизайне класса D: вместо композиции/агрегации использовано наследование;
3) пересечение по именам в названии наследуемого метода (это когда методы делают совершенно разное, но совпали по именам)

1) Первый случай очень редкий. Очень редко но бывает, что метод совпадает по имени и сигнатуре, но не наследуется. Такое может быть, если наследование не public.
2) Второй случай самый распространённый. Бывает сложно отличить владение объектом в единственном экземпляре от наследования от этого объекта. Для различения следует использовать эвристический приём: если класс B может хотя бы теоретически (даже если в коде такого нет и никогда не будет) иметь два объекта класса A, то должна быть композиция/агрегация, а не наследование. (Автомобиль можно отнаследовать от мотора, но — нет, так делать не надо. Поток можно отнаследовать от буфера — у обоих есть схожие методы put, flush, но так как у потока теоретически может быть несколько буферов или не быть его вовсе, то это не отношение наследования).
3) Пересечение по именам не связано с ООП и может происходить (и происходит) в других языках, без ООП.

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

BFE>>>Сигнатуры f одинаковые.
S>>f в вашем примере не виртуальная функция. Т.е. это не эквивалент ни разу.
BFE>Так в этом и состоит "ошибка" исходного примера: если потомок не должен наследовать поведение, то функция не должна быть виртуальной.

Вы пример не поняли, а искать ошибки в нем начали. Ну OK.

BFE>Не согласен. Приведённый пример может демонстрировать три различных проблемы:

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

BFE>3) пересечение по именам в названии наследуемого метода (это когда методы делают совершенно разное, но совпали по именам)

Из-за чего она возникла -- ошибки в дизайне или отшибки в ДНК спорящих на RSDN -- вообще не важно.

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

M>>А в чем превосходство? Обозвать вызов метода отправкой сообщения вряд ли можно назвать превосходством.

Аё>Duck typing. В go и в obj C не нужно объявлять интерфейс с методами- только сигнатуру метода.

В плюсах даже сигнатуру метода объявлять не обязательно

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

BFE>>Не согласен. Приведённый пример может демонстрировать три различных проблемы:
S>Три не может.
Может и больше, так как всё зависит от того, что в голове у автора. Другой автор, не вы, может с помощью этого примера демонстрировать совершенно другую проблему. Страуструп, наверное, сказал бы, что здесь не хватает обобщённых методов. Ещё можно сказать, что задачу (возможно, не проверял) можно разрешить с помощью deducing this...

S>Он демонстрирует возможность или невозможность решить средствами языка программирования одну единственную проблему:
BFE>>3) пересечение по именам в названии наследуемого метода (это когда методы делают совершенно разное, но совпали по именам)
А почему вы отвергаете другие интерпретации? Они ничем не хуже.

S>Из-за чего она возникла -- ошибки в дизайне или отшибки в ДНК спорящих на RSDN -- вообще не важно.
Да, причина не важна. Хотелось бы другого — понять в чём, собственно, проблема. Если в том, чтобы знать приведённый тип объекта, от которого был вызван метод, то нужны либо deducing this, либо чтобы deducing this был виртуальным (чего нет).

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


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

D>

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

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

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

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

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

А что вам не понято в исходном примере?
Тип D должен быть отнаследован непосредственно от A и B, в A и B не должно быть никаких оберток над f, в типе D нужно явно указывать какую из реализаций f мы переопределяем (а в новой реализации нужно еще и явно дернуть унаследованную версию f из нужного класса).

Если вам непонятно нахера это надо, то подумайте вот о чем: есть ли практический смысл в задачках вида "напишите самую длинную последовательность из ключевых слов C++, которая была бы валидным компилирующимся выражением, по типу inline constexpr const char * const f()" кроме как гимнастика ума и банальная эрудиция?

Вот мой пример из этой же области.

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

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

BFE>>Кстати, у вас сигнатуры метода f разные:
BFE>>

BFE>> void f() override A::f {
BFE>> void f() override B::f {

S>Вам альтернативная одаренность не позволила воспринять слова "псевдокод в синтаксисе a la C++" или где? Или вы думаете, что ключевое слово override в C++ является частью сигнатуры?
Или где.
Функции различаются по сигнатуре. Если у двух функций совпадают сигнатуры, значит и сами функции совпадают. У вас две разные функции на псевдокоде в синтаксисе a la C++. Следовательно их сигнатуры не совпадают.

S>Блин, я не против конструктивного общения, но когда человек упорно тупит и не пытается воспринять то, что ему говорят (или уточнить то, что он не понимает), это утомляет.
Для конструктивного общения нет ясного изложения проблематики.

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

BFE>Функции различаются по сигнатуре.

Нет.

BFE>Если у двух функций совпадают сигнатуры, значит и сами функции совпадают.

Да что вы говорите? Может у вас std::sin и std::cos совпадают? Хотя сигнатуры у них одинаковые.

BFE>У вас две разные функции на псевдокоде в синтаксисе a la C++. Следовательно их сигнатуры не совпадают.

Вам бы в церковь, что ли. А то слишком много разного кажется.

BFE>Для конструктивного общения нет ясного изложения проблематики.

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

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

S>Вот оно как: https://habr.com/ru/articles/942582/

S>И автор говорит что настоящий ООП — был только в Smalltalk.

А С# не претендует на настоящий ООП язык? И что ему для этого не хватает?

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

BFE>>Функции различаются по сигнатуре.
S>Нет.
Признаю ошибку.

BFE>>Если у двух функций совпадают сигнатуры, значит и сами функции совпадают.
S>Да что вы говорите? Может у вас std::sin и std::cos совпадают? Хотя сигнатуры у них одинаковые.
Но вы то ещё хотите, чтобы и имена совпадали.

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

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

S>>Да что вы говорите? Может у вас std::sin и std::cos совпадают? Хотя сигнатуры у них одинаковые.
BFE>Но вы то ещё хотите, чтобы и имена совпадали.

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

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

S>>Для конструктивного общения вам бы почитать то, что здесь уже написано. И поменьше выдумывать несуществующих деталей.
BFE>Может стоило сразу написать чего вы хотите, чтобы читатели не мучились в догадках?

Вообще-то все было показано.

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