OberonCore

Это оттягивание конца, а не решение проблемы Порядок загрузки, даже если он четко регламентирован языком, вещь неочевидная и хрупкая. Решение проблемы - избавление от статитеческих переменных за счет вынесения всей необходимой для работы приложения инициализации в одно обозримое место. См. соседнюю тему "о локализации состояния" viewtopic.php?f=27&t=1226&start=40&st=0&sk=t&sd=a.

Нет, для моей задачи это было бы решением проблемы. Раз QA пропустил мастер-версию приложения, то при портировании нужно обеспечить его безглючность/глючность за минимальное время. Нет необходимости развивать программу. То, что Вы предлагаете - это один из возможных способов решения и довольно трудоёмкий, поскольку при переносе я мог бы повносить кучу ошибок. Если бы мне нужно было программу сопровождать, то так стоило поступить, а так - это просто лишняя головная боль. Кстати, согласитесь, Ваше предложение было бы проще реализовать в Обероне, а не Java и Си#.

Запихивание всей инициализации в одно место противоречит структурированию.

У меня есть подозрение, что вы не знаете о чем вообще идет речь. Дабы не скатиться к личным наездам предлагаю обратиться к чему-нибуль более конструктивному, например примерам. Хотя я сходу никакого примера не приведу, потому что проблемы с "неправильной инициализацией" проявляются как раз на больших системах.

Как можно собрать в одно место инициализацию в компонентной системе?
Общий тут принцип - инициализируем при подключении компонента, а подключается компонент - по нужде, on demand...

Давайте по порядку. Comdiv озвучил следующие проблемы (пусть поправит, если не так):
1) Статические переменные имеют неправильные значения, потому что момент их инициализиции зависит от платформы.
2) Существуют перекрестные ссылки, которые в купе с недетерминированным порядком загрузки классов также приводят к тому, что статические переменные имеют неправильные значения.

Первая проблема - это то же самое, что происходит в случае глобального состояния. А именно: одна компонента (мидлет 1) делает с глобальным состояем что-то, чего совсем не ожидает другая компонента (мидлет 2). Решение проблемы - избавление от глобального состояния и локализация его на уровне выше компонент его потребляющих. Пример:


Переписываем так:


Что касается второй проблемы, то при таком подходе она просто не возникает

Comdiv пишет вполне ясно.
И вышесформулированный тезис справедлив.
Как говорят японцы, "гоняйте мух со своей головы".

Японцы молодцы. А вот вы опять по делу ничего не сказали...

Присмотревшись к Вашему варианту, я понял, что он вообще не является решением моей проблемы. Вы не учли, что статические переменные могут быть приватными, и объявлять их открытыми в чужом классе state просто вредно (да, это нарушение принципа структурирования). Также, судя по "Инициализация on demand", по Вы почему-то предполагаете, что нужны эти переменные только для инициализации, а это не так, при изменении s.x1_state во время работы приложения, оно должно изменится для всех классов, а не только x1. Ваш подход решает только проблему с недетерменированной загрузкой класса. Но если Вы более тщательно обдумаете мой первый пост, то заметите, что и моё предложение решало эту проблему.

Я максимально упростил пример. Естественно, что все потроха прячутся за абстрактным интерфейсом.



Если бы и было нарушение, то инкапсуляции...



Оно и изменится, как только вы спрячете все за интерфейсом (x1_state станет ссылкой на абстрактный интерфейс, а состояние, спрятанное за этой ссылкой будет единственным для всех объктов класса X1).



Нет, оно оттягивало конец Попробуйте присмотреться к моемк варианту еще раз с новым пониманием.

А вы бы свои подозрения держали внутри своего мозга.

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

Это кто сказал "гаденькое":
И кто тут на личности переходит?
Так кто сказать не может?

Ну и ну. От вас услышишь. Скрип тормозов.

Непринципиальный вопрос.
Напрасно. Как я понял Vlad ожидал пояснения почему его подход противоречит структурированности.

Давайте жить дружно!
У нас разные задачи, разный опыт, поэтому какие-то расхождения в оценках неизбежны. С этим придётся жить, ничего не поделаешь.

По сути.
Я вообще не очень понимаю, что именно обсуждается в данной ветке и ещё 1-2 ветках (например, о локализации состояния).
Давайте примем во внимание, что:
1. В ОС Оберон и ББ отказ от статических переменных невозможен, т.к. хранение структур данных в оперативной памяти между выполнением команд - основа эффективности этого подхода. (Ср. с подходом UNIX, где "всё есть файл".)
2. Оберон создан (в том числе) для компонентного программирования, так что полную (а не частичную) упорядоченность язык гарантировать не может. Основные проблемы решены избавлением от циклического импорта, и на практике это большой шаг вперёд. (Ср. с примером циклического импорта из C#, приведённым Сергеем Губановым.)
3. Нарушение инкапсуляции одновременно является нарушением принципа структурирования.

Остаётся ситуация с частичной упорядоченностью набора модулей и возможной в связи с этим разновидностью ситуации гонок (race condition) при инициализации.
Здесь вопрос к опытным программистам чёрного ящика: возникали у них на практике с этим проблемы или нет?

Объяснять, почему собирать все инициализации в одно место противоречит структурированности ("разделяй и властвуй")? Можно, я не буду...

Не буду приводить искусственных примеров.
Возьмём реальный модуль HostFiles. При инициализации этого модуля устанавливается глобальная переменная из модуля Files:Реальна ли на практике ситуация, когда модулей, желающих при своей инициализации установить эту переменную, окажется больше одного? Есть ли в этом какая-нибудь опасность?

Кажется я ясно сказал, что. Или нужно повторить?
Можно, но нежелательно...

Уважаемый GUEST, честно говоря, не в первый раз просто не понимаю Ваших постов, видимо, из-за их иногда чрезмерной краткости.
(Похожий эффект иногда с постами Trurl'я бывает.)

Что бы прекратить "базар", нужно, что бы кто-то замолчал...
А публика ЗДЕСЬ сама решит на чьей стороне истинна в конкретном вопросе...