OberonCore

Вполне разумный приём. Главное - мы не "портим" повторно используемые модули ненужными связями.
Мне кажется, что это - (весьма специфическая) разновидность паттерна Mediator.
Но для случая замкнутых (stand-alone) программ мне больше нравится вариант с правильным порядком модулей, передаваемых команде DevLinker.LinkExe или команде DevLinker.LinkDll.

"по злой воле" -- по-существу, речь о том, как лучше сделать какой-то хак.

Надо всё-таки разделять: регулярный проект -- одно, хак -- другое. Тоже бывает, но -- другое.

Отнюдь. Все что я говорил относится к вменяемому разработчику.

Ну вот импортируете вы в правильном порядке модули A и B. Модуль A импортирует модуль C. В какой-то момент модуль C начинает импортировать модуль B. Все ломается...

А чем плох тот порядок, что реализован в Delphi?

Отдельно есть "Project options" в котором мы указываем списком автосоздаваемые модули и доступные модули.

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

Кажется по местной иерархии, это третий способ.

Скорее среднестатистического. Которому плати бАльшую зарплату, у него ж работа сложная - проект сопровождать - баги [свои или предшественника] вылавливать. Да исчо чтоб жилось полегче, думать поменьше, натыкал да и ладно. Дайте струмент, который по ручкам будет бить - "error: ты чё натыкал? проект ломаешь, перетыкивай".

И все [самое главное - конечные пользователи/система образования] на это смотрят как на должное. А цель системы образования - воспитать грамотных разработчиков. Которые будут думать. И которые составят конкуренцию "вменяемым". Если удастся создать критич. массу грамотных, то вменяемым придётся переучиваться, а особо "вменяемым" идти на пенсию.

Извините за оффтоп.

Только давайте не будем путать модули и диалоговые формы, хорошо? Что такое вообще этот ваш "автосоздаваемый модуль"?

Начнём с того, что такое "проект" в компонентной системе

Неясно, "кто кого" импортирует, а главное - что значит "в какой-то момент ... начинает импортировать".
(Это не критика. Просто уточните, пожалуйста.)

dir не имеет отношения к состоянию того модуля, в котором находится. Или по-другому: смена (и только лишь смена) директории никак не влияет на работу модуля.
Но всё-таки, импорт был добавлен в язык для других целей. А Вы предлагаете использовать побочный эффект данной особенности. Хакерством отдаёт : ). К тому же, это особенность реализации. Другие компиляторы данного языка при компиляции не заметив использования импортированного модуля могут его исключить.

Если бы еще этот оффтоп хоть косвенно к теме относился...

Модуль Init импортирует модули A и B. Порядок важен - сначала A, потом B. Модуль А для реализации своей функциональности импортирует модуль C. Наступает "какой-то момент" - добавлние новой функциональности. Модуль C начинает импортировать модуль B. В результате модуль B будет загружен до модуля A не смотря на "форсированный" порядок импорта в модуле Init.

Это будет нарушением основополагающего принципа Оберона: компилятор не должен быть хитрее даже самого тупого программера.

Почему же это хакерство. Порядок загрузки и инициализации модулей с учетом импорта оговаривается явно.

Почитайте сначала определения.

Вы не поняли об чем речь или вам нечего возразить?

Не очень хорошая идея работать с переменными через вызовы процедур на мобильном телефоне.


Нет, Влад. Если открываются в общий доступ приватные переменные - это нарушение инкапсуляции, а если относящиеся к классу переменные выносятся в другой класс - это нарушение структурирования.



Что Вас смущает в моём варианте? То, что некоторые переменные инициализируются прямым обращением к переменным других модулей? Согласен, нехорошо. Так это решается просто: в процедуру инициализации модуля добавляются соответствующие параметры, и инициализация производится по ним. А Вы зачем-то усложняете.