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

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

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

Видишь, как бывает, хотел обидеть других, а обиделся сам

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

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

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

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

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

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

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

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

S>Ну что за бред? Кого я называл недоучкам? Я привел слова автора, неужели не понятно? Ты статью видел, читал?

Ты давай, стрелы не переводи. Этими словами ты озаглавил свою тему. Впрочем, можешь мои слова передать и "автору" тоже.

S>Я уважаю недоучек, еще больше уважаю людей не учившихся в школе.

Ага, Митрофанушка — твой герой.

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

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

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

S>>Ну что за бред? Кого я называл недоучкам? Я привел слова автора, неужели не понятно? Ты статью видел, читал?
R>Ты давай, стрелы не переводи. Этими словами ты озаглавил свою тему. Впрочем, можешь мои слова передать и "автору" тоже.



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

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

R>Ты как-то очень однобоко позаимствовал качества этих людей. Недоучкой ты стал, а вот со всем остальным как-то не сложилось пока.

Объясняю. Из 1000 нестандартных человек — только у 1 что-то сложится. Это как майнинг крипты — в пуле множество народа, все делают общее дело. Все получают награду. И ты там будешь получать награду, даже если за все время ни одного блока не найдешь.

Справедливо ли получать награду от майнинг-пула, если твой реальный выхлоп за 5 лет равен нулю — т.е. реально твои мощности не нашли ни одного блока. Но награду ты получаешь стабильно. Справедливо ли это? Думай.

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

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

Я читаю то, что ты пишешь. Бродить по лабиринтам твоего сознания у меня нет желания. Если ты думаешь одно, а пишешь другое, то это мне тебя жаль.

S>Т.е. ты выискиваешь в моих сообщениях любые поводы, чтобы как-то отыграться?

За что отыграться? Я тебе проигрывал когда-то?

S>Объясняю.

А я разве просил каких-то объяснений?

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

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

S>int main() {
S>  D d;

А что в настоящем ООП должно будет делать

d.f();

?

И что если оба класса A и B наследуются от некоего P, у которого тоже есть f()?
По-моему типичный ООП реализованный в популярных ЯП не стремился к настоящести, а к практической полезности. Поэтому даже множественное наследование и мало кто принял.

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

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

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

Так вот — это вовсе не значит что я согласен с автором.

Тут можно посмотреть значение слова "осудить": https://ru.wiktionary.org/wiki/%D0%BE%D1%81%D1%83%D0%B4%D0%B8%D1%82%D1%8C

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

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

Судя по std::, могу предположить, что это С++. Открываем Библию, читаем:

3.51
signature
⟨function⟩ name, parameter-type-list, and enclosing namespace

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

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

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

А есть где-нибудь онлайн-компилятор Eiffel?

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

_>А есть где-нибудь онлайн-компилятор Eiffel?

Сильно сомневаюсь.

PS. Если что, то писал я по памяти, сверяясь с документацией на официальном сайте. Сам уже давным-давно не экспериментирую с Eiffel.

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

_>А есть где-нибудь онлайн-компилятор Eiffel?

Прошу прощения, предыдущим ответом ввел в заблуждение.
Есть: https://www.eiffel.org/codeboard

Сохранить ссылку как на godbolt/wandbox не знаю как, поэтому вот полный текст примера с разбивкой по файлам:

application.e:

note
    description : "root class of the application"
    date        : "$Date$"
    revision    : "$Revision$"

class
    APPLICATION

inherit
    ARGUMENTS_32

create
    make

feature {NONE} -- Initialization

    make
            -- Run application.
        local
            obj: D
        do
            -- Add your code here
            create obj
            consume_A(obj)
            consume_B(obj)
        end

    consume_A(a: A)
        do
            a.f
        end
        
    consume_B(b: B)
        do
            b.f
        end
end

A.e

class
    A
feature
    f
        do
            print("A::f%N")
        end
end

B.e

class
    B
feature
    f
        do
            print("B::f%N")
        end
end

D.e

class
    D
inherit
    A
        rename
            f as f_A
        redefine
            f_A
        end
    B
        rename
            f as f_B
        redefine
            f_B
        end
feature
    f_A
        do
            print("D's for A::f%N")
            Precursor
        end
    f_B
        do
            print("D's for B::f%N")
            Precursor
        end
end

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

S>Очень часто я привожу новости разные, которые предлагаю обсудить. Или осудить, как в данном случае.
S>Так вот — это вовсе не значит что я согласен с автором.
S>Тут можно посмотреть значение слова "осудить": https://ru.wiktionary.org/wiki/%D0%BE%D1%81%D1%83%D0%B4%D0%B8%D1%82%D1%8C

Ты же не написал "осуждаю" — ты написал "осудите". Это откровенный наброс на вентилятор. И заголовок темы недвусмысленный.

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

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

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

S>>>ИМХО, ОО-язык, который не позволяет получить такой эффект, настоящим не является, т.к. не позволяет использовать возможности полноценного наследования (включая множественного) в полной мере. Соответственно, таковыми не являются ни SmallTalk, ни C++, ни Java...
S>>А какая-то заметная практическая польза от этого могла бы быть? Если я правильно понимаю, в С++ желаемый эффект достигается композицей (визиторами , двойной диспетчиризацией).

S>Практическая польза в том, что если следовать именно объектному подходу, то мы можем прийти к необходимости иметь класс D, отнаследованный от A и B. При этом в A и C есть виртуальный метод с одним и тем же именем, и одинаковой сигнатурой. Но выполняющий при этом разные задачи.

S>Например, это может быть метод dump, который в классе TraceCollector сбрасывает куда-то накопленную трассировочную информацию, а в классе TemporaryBuffer -- флуширует содержимое временных буферов.

S>Если мы делаем какой-то класс WriteAheadLog, который наследуется и от TraceCollector, и от TemporaryBuffer, то возникает вопрос: как быть, если метод dump в WriteAheadLog должен быть перекрыт. Причем так, чтобы версия dump-а от TraceCollector-а перекрывалась отдельно и независимо версии dump-а от TemporaryBuffer.

S>В C++ мы не может это сделать. ЕМНИП, мы можем только создать WriteAheadLog::dump, который будет работать и как TraceCollector::dump, и как TemporaryBuffer::dump (цынк: https://wandbox.org/permlink/jOQygqExzfoOdrAs). А это совсем не то, что нужно.
S>Не можем сделать и в SmallTalk, т.к. там вообще множественного наследования нет.

S>Достичь нужного эффекта, наверное, можно через какие-то обертки. Но это именно что костыли.

S>Тогда как в языке с полноценной поддержкой ООП все это должно решаться без костылей средствами самого языка.
S>Если не решается, значит поддержка ООП не полная. Собственно, на этом все.

S>PS. Я так понимаю, что здесь разговор не столько о практической пользе, сколько об определениях и соответствии этим определениям.

В ООП у вас есть только объекты и их интерфейсы, с ними вы и работаете. Наследование не обязательно, равно как и знание "пользователя" объекта d, что его метод f реализован через наследование откудато, это деталь реализации объекта d. Никаких приведений типов (классов) нет, вы работаете только с объектами. Соответственно, у d может быть только один свой метод f, который будет всегда вызываться, куда бы вы объект d не передали. И у него могут быть свои отдельные методы f_a, f_b которые будут делать свои вещи, реализованные каким-нибудь образом, например, через композицию (большинство языков) или комбинацию методов (CLOS) или переименование (Eiffel). И это тоже лишь деталь реализации.

Все эти дополнительные навороты, конечно, бывают полезны, но не имеют к ООП особого отношения, в том смысле, что не определяют "ООПшность".

А как в Eiffel происходит обработка "вызова неизвестного метода" и возможно ли её переопределить?

Пример на псевдокоде:

class MethodTracer (log: Printer) (orig: Object) =
  object
    on (message: any) do
      result := (orig << message);
      log << orig << " RECEIVE: " << message << "; REPLY: " << result << endline;
      return result;
    end
  end

Насколько я понимаю, в SmallTalk'е и на Ruby такие прокси-обёртки делаются легко и не принуждённо, во всяких Java приходится изворачиваться с рефлексией. А как в Eiffel?

P. S. Это кстати, ещё и немного ответ на вопрос, чем "вызов метода" отличается от "отправки сообщения", который там выше задавали некоторые другие люди.

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

_>В ООП у вас есть только объекты и их интерфейсы...

Простите, бред поскипал. Рассуждения про сферических коней в вакууме не интересны от слова совсем.

_>А как в Eiffel происходит обработка "вызова неизвестного метода" и возможно ли её переопределить?

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

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

S>Простите, бред поскипал. Рассуждения про сферических коней в вакууме не интересны от слова совсем.

Они не более сферически чем весь Eiffel

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

_>Насколько я понимаю, в SmallTalk'е и на Ruby такие прокси-обёртки делаются легко и не принуждённо, во всяких Java приходится изворачиваться с рефлексией.
Так в данном случае это отличие динамической типизации и статической, а не особенности ООПшнсти. Во всяких Java вызов неизвестного метода просто не может произойти, т.к. такой код даже невалиден с т.з. компилятора.

_>P. S. Это кстати, ещё и немного ответ на вопрос, чем "вызов метода" отличается от "отправки сообщения", который там выше задавали некоторые другие люди.
А можно развернуть плз?
Как по мне, вызов метода — это частный случай отправки сообщения: синхронно, с получением результата, ровно одному получателю.

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

·>Так в данном случае это отличие динамической типизации и статической, а не особенности ООПшнсти. Во всяких Java вызов неизвестного метода просто не может произойти, т.к. такой код даже невалиден с т.з. компилятора.

ООПшность динамична по определению: только объект, в общем случае, знает какие сообщения он может обработать и как, а не компилятор. Объект может находится в другом процессе, на другой машине. Во всяких Java через рефлексию можно попробовать вызывать любой метод у любого объекта. Во всяком случае можно было раньше. На этом строятся mock-фреймворки, AFAIK, и AOP-фреймворки (Aspect-Oriented Programming).

·>А можно развернуть плз?
·>Как по мне, вызов метода — это частный случай отправки сообщения: синхронно, с получением результата, ровно одному получателю.

Сообщение -- это тоже объект, с ним можно делать всё то, что и с другими объектами, до, после, во время обработки. Методы -- это реакции на сообщения, практически просто вызов процедуры по указателю из VMT. Метод "принадлежит" объекту (классу, интерфейсу), сообщение -- нет, оно само по себе. Можно сохранить (в переменную) ссылку на метод (с объектом или без), но не параметры, либо сохранить замыкание с телом-вызовом метода.

obj.Foo(x, y);

var objFooRef = obj.Foo;
objFooRef(x, y);

var fooRef = TheObj.Foo;
fooRef(obj, x, y);

var fooCall = fun (obj: TheObj) -> obj.Foo(x, y);
fooCall(obj);

--

obj.Dispatch(new Foo{x, y});

var foo = new Foo{x, y};
obj.Dispatch(foo);

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

_>·>Так в данном случае это отличие динамической типизации и статической, а не особенности ООПшнсти. Во всяких Java вызов неизвестного метода просто не может произойти, т.к. такой код даже невалиден с т.з. компилятора.

_>ООПшность динамична по определению: только объект, в общем случае, знает какие сообщения он может обработать и как, а не компилятор.

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

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

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

Ну, если говорить о "сферическом чистом ООП в вакууме", то да. А так на практике просто идут на компромисы ради бенефитов от типизации. Так же как и чисто статических, навенрное, не может быть в принципе, либо они не слишком удобны на практике в сколько-нибудь широком круге задач. Я имею в виду языки с зависимыми типами, вроде Agda, Coq, Idris и т.п.

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

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

_>Ну, если говорить о "сферическом чистом ООП в вакууме", то да.