OberonCore

Не понял вопроса. Не туда лезем, по-моему.

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

Сердечно одобряю.

Действительно, Дейкстра может быть и трудноват для начинающих.
Поробуйте Д.Гриса ("Наука программирования").
Там помягче, поподробней.
А примеры другие, так что пересечений не будет.

Я высказываю мысль, что можно сколько угодно инкапсулировать стэйт, но если сущность которая его инкапсулирует явно не спущена "сверху" (например в виде аргумента), то это все та же глобальная переменная, вид сбоку. Т.е., если "интерфейс к агенту" компонента получает самостоятельно (компонента "знает", что есть такой агент и знает как попросить у него интерфейс), то этот "агент" - глобальная переменная, как ее ни обзывай и за какие интерфейсы ни прячь.

В общем-то, можно и так назвать в первом приближении.

При внимательном рассмотрении: не будем вводить методов и сквозного управления (когда вызов "гуляет насквозь"). Тогда у нас уже не переменнная (и не объект), а некий активный агент, который сам решает, менять ему своё состояние и как, и или не менять. А окружение только ему что-то посылает.

Далее. Уберём глобальность. Т.е. нет глобальных описателей-указателей. Активные сущности организуются в уровни. Каждая система знает свои подсистемы. Но ничего не знает про свою надсистему, кроме того, что туда можно выталкивать и оттуда можно получать сообщения. (не обязательно дерево. Более адекватен даг уровней). Это уже совсем далеко от "глобальных переменных". Это в чём-то похоже и на ФП. Это в чём-то похоже на dataflow. И, наконец, самое главное, что это в чём-то похоже на реальные системы.

P.S. Во многом это есть в Композите. Но кое-в-чём не так. У меня вот мысли идут другим путём, хотя было интересно вдруг увидеть сходное у швейцарцев.

Да, эта книга у меня тоже есть, её я тоже пытался изучить... Попробую ещё раз...

Так и я про это же. Пусть это состояние БД остаётся в этой самой БД. БД -- это внешний мир, пусть он меняется как угодно -- его проблемы...

Хорошо. Скажите, Вы сами реально используете эту дисциплину? Не один раз на десяток программ, что бы побаловаться или решить серьёзную проблему в программе, а так, что бы методично, от начала до конца? Или Вы считаете, что конкретно Вы можете ограничиться редкими ассертами, а полностью все эти предикаты выписывать необязательно?
Что это даёт по сравнению с тем же equational reasoning в ФП?

А Вы часто применяете equational reasoning?

Увы, нет...

Математики тоже не выписывают полностью свои доказательства, потому что это невозможно.

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

А в чём, собственно, зло?

Математики опираются на ранее доказанные теоремы. В программировании такой опоры практически нет. На что программистам-то опираться?

На простой язык и отлаженные (и, желательно, верифицированные) модули.
В этом смысле модуль = теорема.

Что касается конкретно Дейкстры, увы, не чувствую благодати...

Отсутствие контроля - кто, где и когда имеет доступ к стэйту. В добавок к этому - неочевидные зависимости. В добавок к этому - проблемы в многопоточной среде. Короче, лучше один раз "разгрести", чем сто раз прочитать

Большинство циклов, например, в моей практике тривиально - полный проход и лин. поиск. Когда необходимо построить более сложный случай (например, сортировку какую-нибудь) - выписываю инвариант; прогоняю в уме, как цикл будет приближаться к постусловию и т.п. Это стиль даже не мышления, а ощущения, что ли, алгоритма. В отличие от "наивного" стиля, когда мы пытаемся в уме по шагам выполнять (а в предельном случае - гоняем отладчиком). "Способность выполняться на компьютере является только приятным побочным эффектом" (С) Дейкстра

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

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

Вот это и плохо. Это и есть "компромисс".



Вы не понимаете. Понаставить EXCLUSIVE - мало для того, чтобы все работало Тут упоминался пример парсера, который использует глобальную переменную для индикации ошибки. Толку с того, что вы сделаете эту переменную потокобезопасной - парсер все равно будет глючить в многопотоковой среде. Проэкстраполируйте все это на большую систему со сложными "глобальными переменными" и все станет еще хуже.



Это когда вы пишите:


И у вас все падает, потому что коннект к БД не был заранее засетаплен.

Здесь проблем с "глобальностью" встречаться и не должно.

Если create_window() - свободная функция, то полезть в базу она может только через глобальную переменную. И это проблема. Потому что:
- неявная зависимость от БД
- неизвестно в какую именно БД она полезет, как только приложение начнет поддерживать несколько БД.

Вот этот код избавлен от всех этих недостатков:

Ясно, просто мне показалось, что это фабрика, возвращающая объект window - а его состояния, как известно, инкапсулированы - у которого имеется метод show.