Так деспетчеризация же по имени идти должна, как не принципиально? Дальше идет поиск метода(сам объект/класс и далее по предкам). Нет?

Так а что идентифицирует сообщение?

Ну добавь в сообщение строку с именем, будет тебе имя сообщения. Это не принципиально вообще.

Даже в определении ООП Алана Кея, ЕМНИП, нет ничего об именах сообщений.

А где имена сообщений-то? Мы же про ООП говорим? Диспетчеризация не по имени разве должна быть?

Объект foo, которому мы посылаем разные сообщения (в функции main) и он по разному реагирует на эти сообщения.

Не понял, к чему тут твой пример? Где разные объекты и где разная реакция на разные сообщения, в том числе и неизвестные?

Аналогично, мы можем в том же D создать аналогичный алгебраический тип и передавать объекту сообщения этого типа (вся диспечеризация в рантайме)

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

Но можно взять Ruby, Там тоже можно любой метод для объекта вызвать и объект может сам решать, что ему делать с этим методом. И это уже в run-time. ЕМНИП даже похапе и жабаскрипт так умеют. Тоже мне киллер-фича. :lol:
Так что неубедительно.

Говорят в Smalltalk то что внешне выглядит как отправка сообщений внутри сделано обычными вызовами.

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

а там для отправки уже нужно делать call или cast

call так вообще очень сильно похож на обычный вызов метода объекта.

Это все детали реализации.

Говорят в Smalltalk то что внешне выглядит как отправка сообщений внутри сделано обычными вызовами.

Походу эта дискуссия скоро перейдет в плоскость философии.

Expr1 отправлено процессу Expr2. Что там находится в Expr1 совершенно не важно. Что с этим сделает Expr2 тоже совершенно не важно. Нет даже гарантий, что Expr2 существует. А если существует, то нет гарантий, что Expr1 будет когда-то прочитано. А если быдет прочитан, то нет гарантий, что не будет отброшен. А если будет обработан, то нет гарантий, что это выльется в вызов каких-то функций. И процесс, который отправил сообщение ничего не ждет, как при вызове метода, ничего не пишет на стек, живет себе дальше. Вообще если приземленно, то аналогия будет примерно такой: вызов метода - это письмо, в котором Петя говорит Васе, что нужно сделать. А посылка сообщения тогда - это почта, которая это письмо доставляет от Пете к Васе в запечатанном конверте, и чья ответственность ограничивается только доставкой, при этом находится вне сферы влияния и Пети, и Васи.

то какая принципиальная разницf между отправкой сообщения и вызовом функции?

Именно это и реализуют экземпляры классов посредством вызова методов в ООП.

Почему?

К тому же ты подменяешь вопросы

Вызовы методов.

Где в java обмен сообщениями?

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

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

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

Erlang — это ООП в чистом виде. В отличие от других популярных языков, он сосредоточен на основной идее ООП — обмен сообщениями. В Erlang объекты взаимодействуют, передавая между собой неизменяемые сообщения

Что делает кодовую базу сложной? Есть много вещей, на которые следует обратить внимание. На мой взгляд, главными причинами являются: общее изменяемое состояние, ошибочные абстракции и низкое отношение сигнал/шум (бойлерплейт). Все они распространены в ООП.

Как насчет "научился но не захотел использовать"?

Не думаю, что Линус неосилятор. Что в этих плюсах такого, чтобы их неосилить? Скорее он нежелает их осиливать, вероятно религия не позволяет, ибо Линус, как ни крути, слегонца упорот. А может и не слегонца.

Как минимум тут уже обсуждали неосиляторство Линуса в плюсах

ООП-код является недетерминированным. В отличие от функционального программирования, нет гарантий в получении одинакового вывода при одинаковых входных данных. Это делает анализ программы очень сложным. В качестве упрощённого примера: вывод 2 + 2 или calculator.Add(2, 2) в основном равен четырём, но иногда он может становиться равным трём, пяти и даже 1004. Зависимости объекта Calculator могут изменить результат вычисления трудно уловимым, но основательным способом.

Сейчас вот перечитал в спокойной обстановке и всё равно не понял, в чём вопрос.

Что ты собственно, хотел узнать-то? Бо ничего не понятно...

Никогда такого не делал !!!

То ты гадишь на аксиомы "аксакалов", то доверяешь им