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

Ответ на »сообщение 4864« (Сергей Перовский)
___________________________
>>> Поэтому пока никому не приходит в голову запретить прямые вызовы на уровне среды. Построить VCL на сообщениях, значит заметно затормозить работу.
Ну, я не говорил о том, чтобы запретить все прямые вызовы. Только между объектами, внутри объектов им очень даже место. Тем более, что сейчас ситуация не та, что 20 лет назад. В корпоратичном секторе надежность важнее производительности, а если учесть, что асинхронное взаимодействие на современных процессорах распаралелливается на ура, то производительность вопрос сотни баксов на каждый компьютер...

Ответ на »сообщение 4863« (Стэн)
___________________________
И я про тоже, но вот вся VCL, например, построена по такому принципу. Да и MFC и WinForms ничем в этом плане не лучше.
Надо заметить, что сообщения, вообще говоря, медленнее прямых вызовов.
Поэтому пока никому не приходит в голову запретить прямые вызовы на уровне среды. Построить VCL на сообщениях, значит заметно затормозить работу.
Извечная проблема надежности/эффективности.
Есть возможность в задаче не экономить время - пишите все через посылку сообщений. А если быстродействие критично, придется использовать прямые вызовы, там где это возможно и так, чтобы не было зацикливаний.

Ответ на »сообщение 4862« (Сергей Перовский)
___________________________
>>> Заметте, что Вы сформулировали проблему безотносительно к среде исполнения.
Среда исполнения - это ранавидность рантайма? Native, CLR .NET, JVM? Если да, то это не имеет ни какого значения, так как первый раз я реально столкнулся с этим на Delphi, но если взять C#, например, то ситуация будет аналогичная.

>>> Это не проблема языка или среды - это проблема постановки задачи.
Хм, это как посмотреть.Вот Вы знаете Delphi, знаете, как там пишутся обработчики. Поставили на форму кнопку, нажали на нее и написали реализацию OnClick. И внутри этого OnClick Вы можете написать всё, что угодно. Вызвать любой метод этой кнопки - спрятать/показать кнопку, изменить размеры, перенести ее на другую форму, удалить, в конце-концов. И ни среда, ни язык такого не запрещают. И я не знаю, чья это проблема, но она есть.

>>> Никаких прямых вызовов сторонних методов в теле обработчика быть не должно.
И я про тоже, но вот вся VCL, например, построена по такому принципу. Да и MFC и WinForms ничем в этом плане не лучше.

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

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

Ответ на »сообщение 4859« (Илья Ермаков)
___________________________
Ещё раз подчеркну. Отложенных вызовов должно произойти столько, сколько сообщений было послано.
Ситуация в целом знакомая.
Я обычно использую отложенные действия с упоминавшимся корпоративным диспетчером...
Вообще, выделение действий в отдельные объекты в ББ ГУЕ используется довольно часто, на этом, например, построен единый диспетчер undo/redo для составных документов.

Ответ на »сообщение 4859« (Илья Ермаков)
___________________________
>>> В текущей модели шины сообщения идут неотложенно, стековыми экземплярами.

Значит, текущая модель действительно не решает мою задачу…

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

Уничтоженный объект это только частный случай общей проблемы.
Дело в том, что, как мы знаем, у каждого объекта есть состояние, в виде значений его полей. В общем случае, выполнение обработчика (обработка сообщения) меняет это состояние. Поэтому, можно говорить, что объект находится в стабильном состоянии, если ни один обработчик не выполняется и в нестабильном (переходном) при выполнении обработчика. И если в середине выполнения будет вызван внешний метод, который по цепочке вызовет начальный, либо другой обработчик этого же объекта, то при входе в этот обработчик состояние объекта будет неопределенным. И в общем случае эту проблему нельзя устранить, так как в некоторых частных случаях, при недопустимом состоянии объекта, придется генерировать исключение – «циклический вызов». Не вижу в этом ничего хорошего.

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

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

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

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

Ответ на »сообщение 4855« (Илья Ермаков)
___________________________
Так как же это реализовано в Обероне? Все ли сообщения передаются по шине асинхронно? А следовательно, есть ли очередь сообщений?

В текущей модели шины сообщения идут неотложенно, стековыми экземплярами.
Тогда я не совсем понял, в чем проблема... Сначала Вы вроде написали, что в том, что компонент, который "держит" обработчик, в момент вызова этого обработчика уже уничтожен... Такой проблемы в ББ, как в компонентной системе, быть не может. А про рекурсивный вызов - не совсем понятно.. Требуется, чтобы вместо зацикливания в рекурсивном вызове произошел единственный отложенный? Мы в ББ это обычно пишем через отложенное действие, установленное в очередь диспетчера корпоративной многозадачности. Сколько раз не установи один объект действия, выполнится он потом только один раз...

Ответ на »сообщение 4855« (Илья Ермаков)
___________________________
>>> Что, собственно говоря, и есть в ГУИ Блэкбокса. Generic Message Bug - и проблем не знаем :-)

Я еще раз, более внимательно, перечитал Вашу статью «Некоторые идеи архитектуры Оберон-систем», в частности раздел 2, но так и не нашел самого главного. А именно, решение той задачи, о которой я говорил, там не описано. Вы делаете акцент на том, что Оберон дает нам гибкость по сравнению с тем же Delphi, и при прочих равных это конечно хорошо. Но в том, о чем говорил я, гибкость, как и параллелизм, является – бесплатным бонусом.
Например, Smalltalk, где механизм сообщений реализован на полную катушку, не решает мою задачу, так как в нем – синхронный вызов сообщений и это не функциональный язык (т.е. не всё состояние передается через стек). А это означает, что может быть вызван некоторый метод m1, а из него m2 и т.д… В конце-концов, mn снова вызовет m1, (образуется кольцо) до выхода из первоначального m1, и здесь все накроется.
В Вашей статье в этом плане как-то не однозначно. С одной стороны говорится о том, что ест сообщения и есть шина – вроде, то, что надо. Но с другой стороны, во-первых, Вы пишите, что есть особый обработчик HandlePropMsg. Какой особый смысл в таком делении, если всё асинхронно. А во-вторых, и это самое важное, пишите, что экземпляры сообщений могут создаваться на стеке. Что, по-моему, однозначно свидетельствует о том, что в Обероне синхронный вызов. Так как стек, в случае одного потока, однозначно очистится раньше, чем сообщение будет обработано.

Так как же это реализовано в Обероне? Все ли сообщения передаются по шине асинхронно? А следовательно, есть ли очередь сообщений?

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

Generic Message Bug - и проблем не знаем :-)

О! Баги! Это наше всё! Жо))