OberonCore

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

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

Есть также опасения, что всем захочется улучшенные Host-файлы для собственных компонент, а ваша компонента никому не будет нужна.

Пожалуйста, успокойтесь. Если считаете, что компонента не будет нужна - просто не пишите.

Добавлено: Для предупреждения возможного недоразумения, последнее было сказано тем, кто считает свою компоненту ненужной.

Пожалуйста, не успокаивайте. И я не сказал ничего о нужности или ненужности компоненты (кстати говоря, какой?).

Я просто обращаю внимание на вторую сторону проблемы: в подсистеме Host есть пространство для доработок, и не нужно бояться её модифицировать, решая реальные задачи. Другие люди, вполне возможно, тоже натолкнутся на те же проблемы при решении своих задач, и с удовольствием обновят Host, если кто-то предложит альтернативу.

Значит, надо как минимум, заводить раздел в хранилище компонентов: модификации стандартных модулей.

На Ваше усмотрение, но о какой компоненте говорили лучше спросите себя самого

Заметьте Иван, что Александр этого не говорил.

Я высказался по теме репозитория компонентов как центра дистрибуции.

С вами обоими не соскучишься. Целью моего высказывания не было комментирование Ваших слов.

Я чего-то не понимаю? Зачем изменять стандартные модули? Можно ведь написать новый небольшой модуль с требуемой функциональностью, импортировав в него нужные стандартные.

Например, в BB 1.5 мне пришлось менять модуль National, дабы включить поддержку некоторых юникодных символов. Да и вообще, во многих стандартных модулях есть вставки типа "Fyodor Tkachov, russification", "Ivan Goryachev, russification"

Ну, локализация - это очень специфическая весчь. И то, что его потребовалось "допиливать" говорит только о том, что стандартный - недостаточно стандартен.
ИМХО, надо для каждой страны создать отдельный собственный National, который не придется уточнять.
А то, что в стандартных модулях есть такие вставки - это не есть хорошо.
Это значит, что отсутствует централизованная контора по адаптации ББ в России.
Жаль, конечно, но мож координационный центр какой создать?
Который и будет иметь право на изменения стандартных модулей.

Например: для моих задач понадобилось отлавливать закрытие окна формы ББ. И при необходимости - отменять закрытие. В данном случае мне пришлось переопределить некоторые методы классов Directory и Window из HostWindows + закопипастить всю инфраструктуру открытия окна с некоторыми изменениями + дополнить оконный хук новыми методами, для того, чтобы получить требуемую фичу. То есть дело не обошлось обёрткой потому, что я сам напрямую оконную подсистему не использую. Её используют опять-же системные модули, которые мне менять крайне не хотелось. И это только мой случай. А вот тут в соседней ветке товарищу потребовалось получить путь к исполнимому файлу ББ(работающему в режиме "серверной установки"). Тут или WinAPI или менять HostFiles и никак не применить обёртку. Я как раз про такие случаи говорил.
Да и потом, очевидно, что абстрактно определённые интерфейсы могут попросту не удовлетворять всем требованиям. Тогда их придётся изменить повсеместно.
Ещё вот я в ветке про Линукс предложил реализовать оконную подсистему полностью на механизме отображений и контейнеров. Неизвестно до конца, возможно ли такое при имеющихся абстрактных разъёмах. Такую компоненту тоже придётся распространять отдельно.

Юникод спасёт!

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

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

Правда при этом придётся править стандартные модули из Dev и Std

Не стоит идеализировать "промышленные системы".

А для глобальной переделки есть OMAG и версионность! Или ответвления со статусом отдельного приложения. Как BlackBox Community или типа того.

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