Здравствуйте, Sergey, Вы писали:

S>Ну и, наконец, само требование гомогенности притянуто за уши.

Все модули с точки зрения Runtime system эквивалентны. Раз они эквивалентны, вот я и употребил слово "гомогенность". Что тут притянуто за уши?

SG>> Причем, среда исполнения может динамически загружать и выгружать части
SG>> системы.

S>Весьма странное и совершенно необоснованное требование. Лично я бы от него
S>просто отказался, а модульные системы, умеющие загружать и выгружать свои
S>части в произвольный момент времени, назвал бы интерактивными модульными
S>системами.

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

S>На самом деле, нет никакой разницы в том, есть ли разница между модулями ОС
S>и приложений.

Разница в закрытости или в открытости архитектуры систем. Виндос и Юникс — закрытые не расширяемые системы. Обероны — открытые расширяемые системы.

S>Это не так. Существует куча драйверов для windows, написанных на С++. И
S>рантайм для кернел моде тоже весьма кучеряв — тысченка-другая функций
S>наберется.

Возможно, спорить не стану.

SG>> Компонентная система состоит только из модулей и больше не из чего не
SG>> состоит.

S>Здрасте — рантайм-то забыли

Почему забыли? Runtime system это среда исполнения модулей. Компонентная система — это таже модульная система плюс ООП. Runtime system никуда не пропадает, а даже усложняется (в нее, например, пихается сборщик мусора, менеджер процессов активных объектов и т.д.)

S>Осталось объяснить общественности, что ты понимаешь под "полиморфными
S>переменными".

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

S>Файловый ввод/вывод и оконная подсистема в windows —
S>объектно-ориентированные.
Какие-то части у нее ОО, а какие-то не ОО. Поэтому в целом она не компонентная.

SG>> Следствие 1
S>Следствие из чего?
Следствие скрещивания Модульности и ООП. Модульность диктует ограничения налагаемые на ООП.

S>Дай определение абстрактного класса.
Вы что сами не знаете? С помощью абстрактного класса задается интерфейс полиморфной переменной т.е. ее статический тип.


SG>> Следствие 2
SG>> В общем случае в динамической компонентной системе задача удаления
SG>> более не нужных объектов может быть решена только во время исполнения,
SG>> а не во время написания компонента. Таким образом, компонентные системы
SG>> в общем случае не могут функционировать без встроенного в среду
SG>> исполнения сборщика мусора. (В частных конкретных случаях могут, но в
SG>> общем случае — нет)

S>Еще как могут.

Решите пожалуйста следующую задачку в общем виде:
Вы пишите модуль внутри которого создаете объекты, причем, Вы должны сообщать внешнему миру адреса некоторых своих объектов. Как Вы будуте принимать решение об уничтожении объектов адреса которых Вы сообщали внешнему миру? Как Вы сможете внутри своего модуля расставить на каждый NEW(x) соответсвтвующий ему DISPOSE(x)?



SG>> Следствие 3
SG>> Поскольку между модулями операционной системы и модулями пользователя с
SG>> точки зрения среды исполнения нет ни какой разницы, то вся
SG>> ответственность за безопасность и надежность системы накладывается
SG>> именно на среду исполнения.

S>Почему не на железо?

Вы думаете что пошутили, да? Как бы не так! В будущем оберонистая Runtime system разумеется будет реализована в железе.


SG>> Компонентные программы, например, можно писать на Оберонах.3.2

SG>> http://www.inr.ac.ru/~info21/info/qtocop.htm

S>Гы-гы. Там написано, что Обероны не удовлетворяют в полной мере требованиям
S>КОП.

Опять Вы думаете что пошутили, да? Там написано что первые версии оберонов, а именно Oberon и Oberon-2 разрешали межмодульное наследование. Следующая версия Оберона (№3), появившаяся целых десять лет назад, — Component Pascal уже имел ключевые слова EXTENSIBLE, LIMITED, ABSTRACT позволяющие программисту полностью контролировать межмодульное наследование (расширение) типов. В настоящее время одной из последних версий оберона является Active Oberon, на котором в 2000 году была написана операционка Aos (Active object system) BlueBottle. Сейчас разрабатываются следующие поколения оберонов, например, Zonnon — версия оберона включающая в себя и активные объекты и много чего другого вкусного — под платформу .NET.