OberonCore

предисловие: может, это уже обсуждалось, а моё поиск-фу плохое, тогда ткните, пожалуйста.

заметил тут за собой, что в процессе обсуждений не всегда делаю разницу между понятием «компонент» и «библиотека». а разница есть, и довольно важная, как мне кажется.

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

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

в качестве примера можно взять TextModels и TextMappers: это скорее библиотеки — для «длинных строк» и простого их парзинга. и они используются в BBCB повсеместно, никого такая зависимость особо не напрягает. а вот TextControllers и TextViews уже скорее компоненты, которые вместе реализуют кубик «редактор текста» — используя библиотеки для «длинных строк».

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

то есть, мне кажется, что имеет смысл различать компоненты и библиотеки именно по критерию «повторного использования кода». кишочки, например, можно использовать для создания новых контролов, в которых нужны элементы типа редактора строки и др. тот же комбобокс использует редактор, попап-список, и листбокс-like список в различных комбинациях. выделение кишочков в библиотеку позволит проще создавать новые специализированые типы контролов. (опять таки, CFrames тут взяты как удобный пример, а не как руководство к действию.)

фрэймы и порты, кстати, тоже скорее библиотеки, а не компоненты.

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

Эта тема (компонентов) постоянно обсуждается (в том числе на конференции и Днях Оберона). Но она настолько размазана по пространству, что точно указать контекст сложно.

Клеменс Шиперски главным образом определяет разницу между библиотекой и компонентом по отношению к пользователю.





Szyperski C., Gruntz D., Murer S. Component software: beyond object-oriented programming. 2nd ed. London: Addison-Wesley, 2003. 589 p.

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

вот да, у меня в голове что-то похожее на это крутится. отсюда получается желание герметичности компонентов — чтобы пользователь не парил мозг, собирая себе нужные конфигурации из кубиков. ведь в принципе компонентная среда (BBCB, Oberon) на самом высоком уровне выглядит как конструктор, детальки которого склеиваются инспектором и скриптовым языком. просто скриптовый язык в этом случае тоже оберон — который в силу простоты вполне для такой задачи подходит, пользователю не надо учить стопицот нюансов языка, чтобы простые склеечки и даже несложные алгоритмы на нём писать.

то есть, «герметичность» определяется конктретно как «компонент должен как можно меньше зависеть от других компонентов; но может зависеть от библиотек». при этом желательно, конечно, зависеть только от библиотек, которые уже есть в системе, или которые возможно поставить буквально парой несложных движений (возможно даже полуавтоматически).