OberonCore

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

Фактически сейчас у нас получается, что любая новая програма является подсистемой самого ББ. Может встраиваться в среду и так далее. Это очень здорово и замечательно, особенно когда речь идет об обучении. Но предположим, что мы занимаемся на ББ не обучением, а конкретными разработками. Тогда получается, что все, что мы пишем является подсистемой ББ(если не производить ухищрений, то она даже обитает в папке с ББ). В более сложной програме(в дальнейшем я буду называть это проектом) у меня может быть несколько своих подсистем. Только они уже будут не подсистемами ББ, а скорее подсистемами подсистемы. Это все конечно решается, но все равно некоторыми "заплатками" и самоделками.

Лично мне кажется, что само понятие проекта, как единицы если не языка, то хотя бы структурирования файлов очень полезно. В том числе и потому, что мне кажется, что идеологически не верно рассматривать ББ, как некоторый ящик, который варится исключительно в себе(то есть если я беру и приношу на дискетке (:)) свой проект, мне надо не просто запустить компилятор, а сначала этот проект встроить в ББ).

Установите несколько Блэкбоксов, каждый из них - свой отдельный "проект".

Ну да, плюс рабочие профили... Поскольку среда мала, можно завести её на диске ровно столько раз, сколько хочется

А если приходится работать с переделкой самого "сердца" среды, то собирается монолитный BlackBox.exe на 12 Мб, и рядом с ним ведётся проект...

Хотя С УМОМ введённая концепция пакетов нужна.

Принципиально - опять же классная идея. Модернизировать ядро, да и всю остальную систему под конкретную задачу. На практике... в общем не очень красиво. Каждый раз пересобирать систему(учитывая то, что все это надо делать вручную) довольно накладно. Принципиально, если бы был нормальный пакетный менджер, или мастер установки, который бы сам производил копирование файлов и настройку менюшек с учетом устоновленных компонент, то это бы решило проблему. Правда создало бы свои...

Поддерживаю. И даже назвал бы вопрос концептуальным. В свое время, из единого текста программы выделили процедуры, затем разбили на модули. Следующий уровень абстракции - подсистема модулей. Все направлено на систематизацию, организацию, упрощение восприятия сложной системы. Неограниченная вложенность подсистем (или по крайней мере достаточно глубокая) - тоже мера упорядочивания информации.
К сожалению, нынешние файловые системы могут предложить только древовидную иерархию, тогда как зависимости между подсистемами (как и между модулями) больше напоминают сеть.

Здравствуйте!
Извиняюсь, что сразу не представился - было сильное желание выразить мысль. Работаю программистом в банке. Давно читаю ваш форум, но не участвовал, поскольку нет большого опыта работы в среде. Однако, являюсь большим поклонником Оберона и всего с ним связанного и общие вопросы обсудить завсегда готов.

Здравствуйте, приятно познакомиться!

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

А дальше требуется какая-то возможность описывать структуру (в терминах модулей и их связей) отдельных компонент, объявлять некоторые модули как внутренние для компонента (т.е. запрет от импорта снаружи), составлять более крупные компонентны из более мелких...
Это должен быть отдельный механизм нового уровня. И спец. декларативный язык наверняка... (Об этом много говорил на Королевстве Делфи Р. Богатырёв, говоря о таком языке, как о языке описания "кластеров модулей").

В итоге имеем то, что без продумывания и вырастания из потребностей конкретных проектов (например, проекта ОС), "с кондачка" ничего не выйдет...
Лично я, например, пока ещё не имею в голове картины того, как это должно быть. Поэтому и предпочитаю оставаться в рамках одноуровневых подсистем, пока таковой картины не будет...

Эти вопросы ранее обсуждались здесь http://forum.oberoncore.ru/viewtopic.php?f=1&t=439 и здесь http://forum.oberoncore.ru/viewtopic.php?f=2&t=489

Почитал предлагаемые решения. У Руслана Богатырева очень масштабный взгляд на проблему - разные виды пакетов с учетом асинхронности среды выполнения и т.п. Начать хотелось бы с чего-то попроще. Поскольку задача наша сформулирована, я подытожу лишь основные требования к системе модулей (поправляйте, если что):
[list=]
Наглядное описание состава системы и связей внутри нее;
Ограничение на видимость, наследуемость элементов каждого модуля системы. Ограничение на запись/чтение их значений;
Предъявленные требования должны выполняться при условии вхождения модуля в состав системы (пакета);
[/list]
Несколько раз переписывал свое сообщение и до конкретного предложения так и не дошел. Приведу цепочку своих рассуждений, чтобы можно было выявить ошибки. Ничего нового в них нет, явно или неявно повторяются уже предлагавшиеся варианты, но вдруг кого-то наведет на мысль...
Итак, организация множества модулей в условную систему, по-моему, не привносит в нее ни одной радикально новой черты или свойства (всеми перечисленными свойствами обладает и каждый модуль в отдельности), соответственно, незачем и порождать новые сущности.
Первое тербование выполняется априори: модульная структура легко составляется по разделам IMPORT каждого модуля. Если нам известны модули, составляющие систему, то структура системы очевидна.
На уровне модуля, вообще ничего не должно изменяться, в связи с его входом в состав системы (или даже нескольких). Он по своему "положению" не может ничего знать о структуре, которая, как мы договорились, является следующим уровнем абстракции.
Получается, нам нужна отдельная структура, которая бы содержала информацию о новой организации модулей (системе). А также могла обеспечить выполнение остальных требований.
Структурной единицей оберон-систем является модуль. Попробуем его подставить на требующееся место. Пусть это будет "описательный" модуль, который станет признаком системы. Дальше я крутил его и так и сяк, но удобного решения не нашел. Выделилось 2 крайних варианта.
Первый вариант. Он будет импортировать все модули, входящие в систему и "перекрывать" их интефейсы. SYM-файлы остальных модулей системы пусть считаются неактивными или вообще удаляются. Работа с системой осуществляется через единственный интерфейс "описательного" модуля.
Минус: система не привязана к описательному модулю. Удаляем его - и перед нами все раскрыто.
Второй вариант. Все модули системы импортируют "описательный". Тогда его невозможно исключить из системы. Однако, в таком случае, он не будет явно знать о составе системы и не сможет перекрывать их интерфейсы.
Единственным результатом моих рассуждений, на данный момент, явилась формулировка противоречия для построения системы модулей: "Нужен модуль, который являлся бы неотъемлемой частью системы и, с другой стороны, знал все ее составляющие и мог перекрывать их интерфейсы." Так-как в модульной структуре все связи односторонние, получается, в идеальном варианте, наш "описательный" модуль должен быть и "на входе" и "на выходе" системы (в самом начале дерева импорта и в самом ее конце).
Теперь беремся за АРИЗ и предлагаем варианты решения противоречия!

Здесь все мысли крутятся вокруг: "более высокий уровень в иерархии нужен". Однако, есть ли у кого-нибудь практическая задача которую он собирается решить введя этот уровень? Расскажите об этой практической задаче. Может быть она имеет другое решение? А может быть её вообще нет?

Задач нет. Есть всего лишь скромная фраза фраза в документации: "This module has a private interface, it is only used internally"

По сути на данный момент она есть - файловая система. У этого есть два минуса - во-первых, для ББ она внешняя, что вредит идеологии, во-вторых, то, с чего все началось - отсутствует гибкость.
Теперь что касается вашего предложения сама идея этого заголовочного файла попахивает Сей с плюсами. Но если все-таки развить идею, то все довольно просто.
Во-первых, "проектный модуль" должен надеваться на систему сверху, потому что как уже было сказано, модули должны работать и сами по себе без всякого проекта, и кроме того один модуль может входить в несколько проектов одновременно(в данный момент это невозможно и это крайне противно). Правда зачем мутить воду с перекрытием интерфейсов я не понимаю. Мы и так обычно делаем интерфейсный модуль в проекте. От "проектного модуля" требуется только чтобы он мог по внутреннему названию модуля выдавать его физическое название и обратно(сейчас внутреннее и физические названия просто совпадают). Таким образом в нем должен быть просто набор пар строковых констант, одна из которых указывает внутреннее имя(например формата [projectname][modulename], сейчас вместо имени проекта стоит имя подсистемы, или если быть точнее папки в файловой системе), другая физический адрес файла с модулем. Сюда же для удобства можно запихать информацию о состоянии рабочего стола для данного проета(да и кучи всего другого вплоть до комплектации меню).Таким образом мы отрываемся от файловой системы, правда взамен приобритаем лишний файл в проекте.
Да, только что вспомнил, почти тоже самое сделано а Delphi, там есть файле .dpr, который фактически хранит информацию о проекте.

Все можно сделать другими способами. Вопрос в удобстве. Как я уже говорил, я пользуюсь скриптом Info21, который фактически эмулируеи нужный мне дополнительный уровень иерархии. Если бы его не было, то, да, мне было бы жить гораздо сложнее.

Перевод этой фразы на русский язык такой: "sym-файл этого модуля вы от нас не получите".

Отнюдь. Перевод такой - "здесь у нас в межмодульной защите дырка, но мы вам её не покажем". А sym-файлы с полным ББ поставляются.

Бага там или фича никому не известно - сим-файла нету и всё - что хочу то и ворочу.


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

Очень, кстати, удобно. Пишешь свою подсистему, но символьных файлов её модулей никому не даёшь, за исключением одного модуля - модуля фасада подсистемы.

Я так сразу не помню - модуль Meta без sym-файлов работает?

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

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

P.S. На самом деле сочетание Kernel+SYSTEM+Meta позволяет спокойно (и относительно безопасно) оперировать и локальными объектами модулей. И никакого контроля за этим сейчас нет