p
А что в нашем мире не генерирует asm в конечном итоге?
Есть же всякие vm, поедающие байткод.
Size: a a a
2021 February 25
KR
И то, само слово "объект" тут не в ООПшном значении, а в смысле "Значение типа абстрактных данных". В ООП немного иначе все устроено, но это другая история и другой разговор совсем. Потому что есть только один объектно-ориентированный язык by-desighn, и ровно одно семейство, в котором можно ООП выразить синтаксически. Во всех остальных языках с классами и объектами - это не ООП, а Abstract Data Types
KR
В случаях, когда message-passing (корень ООП) не выражен в языке синтаксически, ООПшная реализация от языка не зависит и строится над языком.
MK
И то, само слово "объект" тут не в ООПшном значении, а в смысле "Значение типа абстрактных данных". В ООП немного иначе все устроено, но это другая история и другой разговор совсем. Потому что есть только один объектно-ориентированный язык by-desighn, и ровно одно семейство, в котором можно ООП выразить синтаксически. Во всех остальных языках с классами и объектами - это не ООП, а Abstract Data Types
ты про смолтолк?
KR
Это я все к тому, что когда мы говорим о message-passing там есть понятие "метод взаимодействие С объектом", но это не имеет отношения к диспетчеризации, как таковой, потому что понятие "объект" значит нечто другое
p
В случаях, когда message-passing (корень ООП) не выражен в языке синтаксически, ООПшная реализация от языка не зависит и строится над языком.
честный message passing вроде никто не делает, потому что медленно
KR
ты про смолтолк?
by-design - да, Смоллтолк (и RealTalk, как последователь, но там история интересней и тоньше), а тот в котором можно выразить синтаксически — Lisp
KR
честный message passing вроде никто не делает, потому что медленно
На самом деле, не медленно, просто мало кто вдупляет, в чем его прикол.
KR
Чтобы это понять, мне пришлось прокопать хренову гору публикаций на тему и около.
KR
И то, без парня, который лично потер с Кеем на тему, я бы не разобрался
KR
Цимес, вообще, в проектировании систем именно с точки зрения коммуникации, с разделением сообщений и сигналов.
KR
"Сообщение" в этом контексте - это пожелание. А сигнал - безоговорочный приказ.
KR
На аналогии - вот идет секретарша, несет документы. Ей начальник говорит "Принеси кофе". И если это сообщение, то секретарша донесет документы, а потом пойдет за кофе, или положит их на свой стол, а потом донесет вместе с кофе - короче будет решать сама исходя из ситуации. Например, скажет "Ты дурак? Офис горит, спасаем документы, какой кофе?"
E
На аналогии - вот идет секретарша, несет документы. Ей начальник говорит "Принеси кофе". И если это сообщение, то секретарша донесет документы, а потом пойдет за кофе, или положит их на свой стол, а потом донесет вместе с кофе - короче будет решать сама исходя из ситуации. Например, скажет "Ты дурак? Офис горит, спасаем документы, какой кофе?"
В программах обычно подобное недопустимо. Аналогии с реальным миром плохо работают. И сообщения пожелания тоже.
KR
А в случае сигнала, секретарь может бросить документы на пол и перейти в другое состояние "иду за кофе" или пойти за кофе с документами в руках и там зависнуть, потому что руки заняты держанием документов. И для разрешения этого нужно задать полный набор условий: "Если у тебя в руках документы, дойди до стола, положи документы, развернись и иди за кофе"
KR
В программах обычно подобное недопустимо. Аналогии с реальным миром плохо работают. И сообщения пожелания тоже.
Допустимо, и работает. Там проблема в другом: нет способа описать разницу между сигналом и сообщением в обобщенном виде, и нужно самому определять, какая передача - сигнал ,а какая - сообщение.
KR
Единственный случай, по-моему, где эта разница есть - RealTalk, и то только потому что там нет сигналов, одни сообщения
p
На аналогии - вот идет секретарша, несет документы. Ей начальник говорит "Принеси кофе". И если это сообщение, то секретарша донесет документы, а потом пойдет за кофе, или положит их на свой стол, а потом донесет вместе с кофе - короче будет решать сама исходя из ситуации. Например, скажет "Ты дурак? Офис горит, спасаем документы, какой кофе?"
какой-то fsm
KR
Например, такие штуки писались на PL/1 вполне себе успешно. Да и до сих пор пишутся на чем угодно, часто случайно. Например, когда ты проектируешь взаимодействие серверов через АПИ (пусть JSON), и при этом у тебя в JSON описана группа условий, необходимая для выполнения некоторой задачи. Если условия не выполняются, то и сервер, который это сообщение получил, задачу не выполнит. Вот тебе и message.
KR
Для проектов на PL/1 испольвали т.н. configuration language, в которых как раз и описывалась структура условий и пожеланий, необходимых для выполнения действия.