OberonCore

Подсистемы в BlackBox имеют только один уровень вложенности. Мне кажется было бы логичным расширить это, т.е. имя модуля разбивается на строки в зависимости от регистра. Последняя строка -- имя модуля, предшествуюшие -- путь к модулю.

Какие будут мысли по этому поводу?

А почему не наоборот, может логичнее как раз сузить?

В смысле обобщить...

Может более общим будет разделитель- точка, т.к. можно сюда же деление по версиям вписать.
Например, модуль system.subsus1.modname.1.0.1. Пользоваться так: либо IMPORT system.subsus1.modname, либо указать частично/целиком версию IMPORT system.subsus1.modname.1 (если предполагаем, что с 1.x будет работать, а с 2.0 - нет). Ну и при неполном указании использовать самый свежий вариант, т.е. system.subsus1.modname.1.4.0 если более "свежих" 1.х нет. Правда такой подход усложнит работу, особенно с доками- как выдавать ответ на system.subsus1.modname.1, если изначально шла 1.0 потом добавили 1.1 и 1.3 - исходный или сгенерированный?

По поводу уровня над модулями - в умах "бродят" идеи введения надуровня "кластер", со спец. декларативным языком спецификации связей... Эти идеи развивает на форуме Королевства Дельфи Руслан Богатырев. См. http://delphikingdom.com/asp/talktopic. ... 78#msg4378 и далее.

Более простой и более насущный механизм - без какого-либо изменения схемы именования, но с изменением схемы хранения, распространения, интеграции... Это пакеты. И пакеты в ближайшее время планируется сделать.

только непонятно... зачем все это.....
зачем многочисленные уровни вложенности?
(если очень нужно внутри папки мод(значит и в сим и код), как-то сгруппировать модули, то можно давать самостоятельно им общую часть названия:
Stud/mod/Urok1Uprajnenie1
Stud/mod/Urok1Uprajnenie2
...
)

зачем неявные механизмы импорта("берется самый свежий")?
(как вариант можно хранить исходники модулей разных версий в разных файлах:
Stud/mod/ModuleVer1
Stud/mod/ModuleVer2
....
но само имя модуля будет во всех StudModule, когда пробуем программу с новой версией, то компилируем ее, если нужно откатиться то компилируем более раннюю
тут теряется возможность перехода на исходник "выделил имя модуля где угодно->исходный текст")

(или такие приемы сильно неудобны? или может не везде подходят)

на сколько усложнятся схемы хранения, распространения, интеграции с пакетами?

В этом случае не будет обратной совместимости с языком КП

А вот с делениями на версии не соглашусь. Если меняется интерфейс модуля, то лучше дать ему новое имя, а не плодить совместимые и несовместимые версии.

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

А можно поподробнее о пакетах?

Объяснять дольше, чем один раз потом увидеть...
Частично - развитие идеи профилей в ББ. Реализуется через "монтирование" виртуальной файловой системы. Для рядового пользователя среды выйдет очень просто...

Да не, я в смысле вообще сузить: отменить папочную иерархию и все модули класть в одно единственное объектное хранилище.

Наверное так и будет в пакетах...
Будем ждать

А что Вы понимаете под "объектным хранилищем"?

зачем чтоб все модули совсем в куче то лежали?)
если нужно среду порезать то придется искать ненужные модули
а так хрясь подсистему срезал и доволен(правда все равно нужно связи знать, а то отрежешь чего др импортируют))
как раз текущий вариант оптимален по несложности/полезности...на мой взгляд правда...

Оптимален. Вот он и будет чуть-чуть доработан до ума. Чтобы в хранении подсистем было чуть больше порядка и для интеграции новых подсистем не требовалось правки каких-либо файлов основной среды (Config, добавление пункта в существующие меню и т.п.), т.е. чтобы добавление новых компонент происходило полностью Plug&Play - и наоборот: удаление - просто Delete&Enjoy

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

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

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

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

Ну, в этом тоже можно отыскать смысл.

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

Например, если файловая система полская.
Вообще, мне кажется, что нынешня схема именования модулей вызвана ограничениями DOS на длину имени файла.