OberonCore

В связи с неконтроллируемым ростом всяческих и разных подсистем хотел бы посвятить эту тему регламенту построения дерева подсистем.

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

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

Допустим,
Libs (или Intf) - для набора модулей, описывающих интерфейсы внешних библиотек,
Tools - для всяческого инструментария,
Widgets - набора GUI-компонент,
Science - средства расчёта, наукоёмкие компоненты,
OS - ОС-средства
и т.д.

Ваши мнения?

Гиблое дело... Подвести под единый регламент всех разработчиков, которые могут и не подозревать о существовании друг друга...

Делали Вы подсистемы, включали их в проекты, внедрили, сопровождаете... И тут появляюсь я и говорю: Ваши подсистемы не вписываются в наш общий регламент - извольте все перестроить/переименовать.......

Ominc вели список http://www.oberon.ch/blackbox/subsystems.html для предотвращения коллизий имён. Но он брошен...

Мне кажется, что ББ - это такой конструктор саморазвиваемый. Поэтому ИМХО должна оставаться базовая "чистая" версия, а на ней каждый лично для себя достраивает то, что ему нужно. Если окажется, что нужно не только ему, то можно собирать в некую общую библиотеку модулей по типу Зинна.

У линуксоидов линейная пакетность - и ничего, живут уже сколько лет...

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

Кроме этого аргумента других серъёзных причин не видно, однако, для того, чтобы воплотить эту идею, придётся внести коррективы в язык. Оно того стоит?

А со временем надоедает ставить разные подсистемы, поэтому на практике эффект свалки - вещь довольно редкая.

Посоветую пробовать подсистемы в серверном режиме -- в "рабочих папках" в особой папке "Свалка", которую всегда удобно стереть одним махом

Подписываюсь (делаю так же)

Я вообще имею отдельный ББ в C:/Temp для "мусорных" целей... Чем эти профили клепать, иногда проще копирануть целиком )

Какие профили?

Рабочие каталоги...

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

Не помешала бы кнопка "феникс" с двумя режимами )
1. Удалить все, что не относится к базовой конфигурации (для очистки экспериментальной копии ББ)
2. Удалить все, что не относится и не используется открытым модулем (для минимизации размеров готовой программы)

Удалить каталог "Экспериментальный". Скопировать каталог "Базовый" в "Экспериментальный". Эти кнопки есть в файловом менеджере... Эта задача не разрешима. (в общем случае) Про модули реализации, которые втыкаются в абстрактные разъёмы, знают только сами модули реализации.