Ответ на »сообщение 4860« (Стэн)
___________________________
При такой схеме, в случае параллельности, бесплатным бонусом является то, что нет необходимости использовать какие-либо примитивы синхронизации для полей объекта. Так как среда гарантирует, что два обработчика не будут вызваны одновременно ни в одном потоке, ни в нескольких.


Вот этот момент не очень понятен. Откуда гарантия того, что кто-то не захочет обратиться из другого потока к полям объекта во время выполнения обработчика? Или обращение к полям тоже происходит через посылку асинхронного сообщения?

В минувший уик-энд в Сан-Диего (США) прошла 3-я Международная конференция по истории языков программирования (History of Programming Language Conference, HOPL-III), которая традиционно проводится примерно раз в 15 лет под эгидой профессиональной ассоциации ACM.

На ней с докладом "История языков Модула-2 и Оберон" выступил проф. Никлаус Вирт. На предыдущей конференции HOPL-II, прошедшей в 1993 г. в Кембридже (США), он представлял доклад "Recollections about the Development of Pascal". В Сан-Диего помимо выступления проф. Вирта были представлены доклады по языкам Erlang, AppleScript, C++, Self, ZPL, Emerald, Lua, Haskell, Fortran, BETA.

Доклад Никлауса Вирта "Modula-2 and Oberon" опубликован на EuroProg. В ближайшие дни будет размещён перевод на русский язык. Полный сборник докладов конференции HOPL-III также представлен на EuroProg. Детали см. rbogatyrev.livejournal.com

Ответ на »сообщение 4872« (Сергей Перовский)
___________________________
>>> С тех пор, как появился actionlist, я ничего в OnClick не пишу и вообще разрабатываю "бизнеслогику" до интерфейса.
>>> От самой навороченной кнопки требуется только передать управление соответствующему action-у.
Я не понял, в чем разница-то? Ваш OnExecute неявно назначется OnClick. Все вызовы попрежнему проходят синхронно. Проблема осталась.

>>> Что касается обмена сообщениями, то никто не мешает не публиковать методы и поля объекта. Тогда никаких прямых вызовов не произойдет. Только обработка сообщений.
Конечно, Вы правы, не надо так делать. Только VCL уже так сделана...

Ответ на »сообщение 4868« (Geniepro)
___________________________

Ответ на »сообщение 4861« (Илья Ермаков)
___________________________

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

Что за "корпоративный" диспетчер Вы тут всё время упоминаете? Наверное, Вы имеете в виду кооперативную многозадачность?
Вообще-то, кооперативная многозадачность - путь к ненадёжности - едва избавились от этого в Вин3.1, как Вы предлагаете снова к ней вернуться...
Если зависнет один поток - то в этой схеме всё приложение повиснет, упадёт вся Оберон-система...
Упоминаю не все время, а два раза - при этом во второй раз описался - конечно, кооперативная...
И не совсем уж многозадачность, просто диспетчер очереди отложенных действий, действие регистрируется на определенный момент, затем выполняется, затем при необходимости может переустановить само себя сколько угодно раз.. Такая "квантовая" псевдомногозадачность. Весьма удобна для программирования ГУЯ. Заменяет VCL-вский таймер.
Вооще кооперативка для ГУЯ - самое то, иначе с синхронизацией умучиться можно - если, конечно, вся графика снизу доверху не написана на активных объектах, как в БлуБоттле.
По поводу "зависания" - ББ все-таки не ОС, а приложение, есть ГУЙ виснет, то ничего не попишешь, так написали - хотя на практике не встречалось. Кроме того, можно всегда нажать Ctrl-Break - и Блэкбоксовый гуевый поток сразу откатится на главный цикл сообщений - как ни в чем не бывало.

Ответ на »сообщение 4870« (Стэн)
___________________________
Он берет эту кнопку, кладет ее на форму и реализует обработчик OnClick. Что он там пишет?
Если хорошо знает Дельфи, то ничего :)
С тех пор, как появился actionlist, я ничего в OnClick не пишу и вообще разрабатываю "бизнеслогику" до интерфейса.
От самой навороченной кнопки требуется только передать управление соответствующему action-у.
Пример с интерфейсом вообще не показательный.
Что касается обмена сообщениями, то никто не мешает не публиковать методы и поля объекта. Тогда никаких прямых вызовов не произойдет. Только обработка сообщений.
Регулярно появляются идеи заменить ООП на что-нибудь "более прогрессивное".
Я хочу заметить, что в свое время все попытки сделать язык "чисто объектным" потерпели неудачу. Выжили только языки, сохранившие наряду с объектами и простые переменные.
Точно так-же, мне кажется, мы не сможем убрать из языка "простые объекты" в силу их высокой универсальности и сравнительно низких накладных расходов.

 

Ответ на »сообщение 4870« (Стэн)
___________________________

Та модель, которую я пытаюсь отстаивать, очень похоже на Erlang. Та же изоляция процессов, тот же обмен сообщениями. Но вместо процессов – объекты. Erlang –функциональный язык, а как бы это сделать на императивном? Если это вообще необходимо делать? Вопрос открытый.

Хотя Ерланг и функциональный язык, но в том, что касается процессов - это по сути обычный императив и есть. Каждый процесс имеет свой словарь, который он сам может преспокойно деструктивно модифицировать.
Но вот общение между процессами - действительно чисто на сообщениях. Впрочем, это тоже ближе уже к ООП, чем к ФЯ...

Ответ на »сообщение 4869« (Сергей Перовский)
___________________________
Ну, ни кто ведь не говорил, что это будет легко... Однако фанатизмом здесь и не пахнет. У меня вполне конкретные задачи сейчас, ну и необходимость думать на перспективу.
Я вскользь уже упоминал, что разрабатываю библиотеку для C++. Это модель актеров, и предполагается, что эти актеры достаточно крупные образования – как службы, а не как структура TPoint. И пользователь сам решает, какие классы будут актерами, и будут взаимодействовать через сообщения, а какие классы будут «списками» и будут вызываться напрямую. Здесь все кристально чисто.

Однако на библиотеки далеко не уедешь, так как для повышения надежности разрабатываемой программы нужна поддержка со стороны компилятора, семантическая проверка. Все равно необходим какой-то другой язык, либо расширение существующего. Говорилось, что новые версии Оберонов могут обеспечить массовую параллельность, но кроме параллельности нужны еще некоторые вещи, а Message Bus пока, как я понял, их не дает.

Та модель, которую я пытаюсь отстаивать, очень похоже на Erlang. Та же изоляция процессов, тот же обмен сообщениями. Но вместо процессов – объекты. Erlang –функциональный язык, а как бы это сделать на императивном? Если это вообще необходимо делать? Вопрос открытый.

>>> Невозможно создать действительно сложный объект, содержащий только базовые типы данных, обязательно потребуются объектные поля.
ОК. Ещё раз постараюсь описать задачу. На примере Delphi. Есть кнопка. Её реализация может состоять из кучи методов, полей; поля могут быть сколь угодно сложными – это не важно. Важно то, что Вы эту кнопку полностью разработали сами. Вы отвечаете, что она стабильна, надежна и безопасна. Вы отдаете другом программисту, который делает форму с использованием этой кнопки (нормальный такой компонентный подход). Он берет эту кнопку, кладет ее на форму и реализует обработчик OnClick. Что он там пишет? А пишет он там бизнес-логику. И проблема Delphi в том, что эта бизнес-логика выполняется напрямую из кнопки, и Вам остается только молиться, чтобы он все не порушил, случайно не удалив эту кнопку, или не вызвал какой-нибудь метод, который во время генерации события OnClick вызывать нельзя.
Вот если бы код кнопки был бы изолирован от кода бизнес-логики, то ни каких проблем бы не было. А чтобы такой изоляции добиться, необходимо взаимодействие организовывать с помощью асинхронных сообщений. А пока – имеем, что имеем.

И самое главное. Хочется получить это на уровне языка, чтобы компилятор гарантировал, что таких проблем не будет. Я считаю, что это сделать вполне реально, только вопрос – как лучше всего это сделать? Как это должно быть отображено в языке и какие конструкции должны там быть?

Ответ на »сообщение 4867« (Стэн)
___________________________
Согласен. Но, по-моему, это как раз и означает правильно рассчитать объем каждого объекта, а не размазывать код по одному методу на каждый объект.
Мы тут недавно в этой ветке шумели по поводу того, что иногда удобнее монтировать объект из стандартных, чем наследовать. (Кстати, я отстаивал полезность наследования :))Существует множество наработанных классов: списки, таблицы, перекодировщики и т.д. и т.п. Невозможно создать действительно сложный объект, содержащий только базовые типы данных, обязательно потребуются объектные поля. Если нужно наделить объект списками именованных объектов, я создам поле типа TStrigList, а не буду реализовывать эту функциональность заново. И моему объекту должно быть разрешено непосредственно вызывать методы собственных частей.
Давайте без фанатизьму :)

Ответ на »сообщение 4861« (Илья Ермаков)
___________________________

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

Что за "корпоративный" диспетчер Вы тут всё время упоминаете? Наверное, Вы имеете в виду кооперативную многозадачность?

Вообще-то, кооперативная многозадачность - путь к ненадёжности - едва избавились от этого в Вин3.1, как Вы предлагаете снова к ней вернуться...
Если зависнет один поток - то в этой схеме всё приложение повиснет, упадёт вся Оберон-система...

Ответ на »сообщение 4866« (Сергей Перовский)
___________________________
>>> Объекты объектам рознь. Очень часто один объект является частью другого и тут прямые вызовы должны быть доступны.
А тут я могу задать вопрос: А почему? Это такой способ декомпозиции, когда вместо метода в текщем объекте мы пишем отдельный объект с тем же методом?

>>> Выделить те границы, через которые можно общаться только сообщениями - дело правильного проектирования.
Согласен. Но, по-моему, это как раз и означает правильно рассчитать объем каждого объекта, а не размазывать код по одному методу на каждый объект.

>>> Иначе придется вводить в языке различные категории объектов: для построения сложных объектов одни, а для взаимодействия с шиной сообщений другие.
Не думаю, что это так. Каждый объект общается с другим асинхронно. Но, вот что реально в язык необходимо вводит - это явное управление состояниями, так как сама по себе асинхронность еще сложнее чем IoC.