Ответ на »сообщение 4883« (Стэн)
___________________________
>>>А вот на Delphi/FPC надежность решения будет держаться на честном слове (ни контроля типов, ни сборки мусора, ни стековых объектов).
По поводу контроля типов, требуется уточнение о каком контроле разговор, т.к. в Delphi он прекрасно реализуется.
По поводу сборки мусора мы не договоримся - по моему мнению сборка мусора маскирует концептуальные ошибки в модели. 
Со стековыми объектами тоже не все в порядке. Они провоцируют ошибки аналогичные печально известному переполнению буфера. Стек не должен быть доступен для подобных операций.

Ответ на »сообщение 4884« (Geniepro)
___________________________
>>>Не могу согласиться.
Дык никто не заставляет :)

>>>Программы с двумерным синтаксисом (как в Хаскелле, Оккаме и др.) читаются замечательно...
Еще один термин, который хорошо бы пояснить.
Заметим, что в этой ветке речь идет о языках императивных и понятие области существования переменной вполне однозначно.

Ответ на »сообщение 4882« (Сергей Перовский)
___________________________

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

Не могу согласиться. Программы с двумерным синтаксисом (как в Хаскелле, Оккаме и др.) читаются замечательно... Ведь такой синтаксис вырабатывает элегантный стиль написания! ;о)

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

>>> А где можно посмотреть определение и теоретическое обоснование?
>>> А то Вы употребляете термин, как общеизвестный, а я впервые столкнулся в этих сообщениях.
http://ru.wikipedia.org/wiki/Inversion_of_Control

Здесь во введении написано более понятно
http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf

Про актеров, библиотека на Scala
http://lamp.epfl.ch/~phaller/doc/haller06da.pdf

Ну и вообще, много интересного в этом разделе
http://www.scala-lang.org/docu/papers.html

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

>>>Понятие "сложный" весьма относительно.
Разумеется, и похоже оно у нас разное :)

>>>И если это встроено в язык, то как и какая модель?
Именно поэтому встраивание в язык проблематично: модель нужно выбирать по задаче. Предпочтительнее иметь библиотеки, реализующие различные модели.

>>>Если это модель актеров, то, можете посмотреть на это с другой стороны, параллельность будет целью, а избавление от IoC будет бесплатным бонусом.
А где можно посмотреть определение и теоретическое обоснование?
А то Вы употребляете термин, как общеизвестный, а я впервые столкнулся в этих сообщениях.

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

>>> Пользовательский интерфейс не может быть слишком сложным по определению - иначе им пользоваться не возможно :)
Понятие "сложный" весьма относительно. Вот я бы хотел, чтобы интерфейс был более интерактивным, контекстнозависимым. Такой интерфейс не очень-то легко разрабатывать. Главное, чтобы он бы удобным.

>>> Если же "бизнеслогика" оказалась сверхсложной, то построить для ее объектов асинхронное взаимодействие труда не представляет.
Опять вопрос. Как делать? Каждый своими руками, или это должно быть встроено в язык? И если это встроено в язык, то как и какая модель?
Если это модель актеров, то, можете посмотреть на это с другой стороны, параллельность будет целью, а избавление от IoC будет бесплатным бонусом.

>>> Вывод: не стоит исключать из языка механизмы синхронного взаимодействия.
Согласен. Только я не говорю, что надо исключать. Я говорю, что есть места, где от синхронности необходимо отказаться.

Ответ на »сообщение 4878« (pepper)
___________________________
>>> Хорошо. Как будет выглядеть взаимодействие для получения значения какого-либо свойства? Например, когда в обработчике одного объекта понадобилось значение поля другого объекта?
Я еще раз хочу обратить внимание, что не каждый объект обменивается с другим только через сообщения. Тоесть не все объекты актеры. Состояние каждого актера выражено в терминах обыкновенных объектов с синхронным взаимодействием.
Что касается получения какого-нибудь значения от другого актера.
1. Необходимо послать сообщение о запросе значения.
2. Необходимо дождаться получения ответа.
И понятно, что внутри обработчика, пославшего сообщения, ответ мы не получим. А если очень хочется, то необходимо послать ответ, перейти в специальное состояние, дождаться ответ, и продолжить...

Ответ на »сообщение 4874« (Стэн)
___________________________
>>>Я не понял, в чем разница-то? Ваш OnExecute неявно назначется OnClick. Все вызовы попрежнему проходят синхронно. Проблема осталась.
Почему-то я сталкивался с этой проблемой только в одном случае: при остановке отладчиком обработчика onShow (ну или onActivate).
Теоретически я понимаю, что можно в обработчике события вызвать это событие вновь, но смысла в этом не вижу. Не представляю, насколько нужно не понимать собственную задачу, чтобы спровоцировать такую ошибку.

>>>Только VCL уже так сделана...
И прекрасно работает...
Пользовательский интерфейс не может быть слишком сложным по определению - иначе им пользоваться не возможно :)
Поэтому я не вижу необходимости на этом уровне вводить такие драконовские ограничения.
Если же "бизнеслогика" оказалась сверхсложной, то построить для ее объектов асинхронное взаимодействие труда не представляет.

Вывод: не стоит исключать из языка механизмы синхронного взаимодействия. 

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

3. Выделит общие данные в отдельный объект-актер и взаимодействовать с ними через сообщения.


Хорошо. Как будет выглядеть взаимодействие для получения значения какого-либо свойства? Например, когда в обработчике одного объекта понадобилось значение поля другого объекта?

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

Во-первых. У объекта в другом потоке нет указателя на объект, а только копия специального proxy-объекта, через который можно посылать сообщения данному. Поэтому, поля не доступны и к ним обратиться из других потоков нельзя, только из обработчиков данного объекта.
Другое дело, что поле может быть неким указателем на общие данные, которые разделяются и здесь есть три варианта:
1. Доступ к общим данным необходимо будет синхронизировать явно.
2. У каждого своя копия общих данных и они синхронизируются через сообщения.
3. Выделит общие данные в отдельный объект-актер и взаимодействовать с ними через сообщения. Например, консоль - разделяемый объект. Доступ к ней можно организовать через критическую секцию, а можно через актера, которому буду посылаться сообщения: ВыведиНаКонсоль( текст ).