Накопилось несколько вопросов на тему модульности и компонентности:

degor>Ну и чем вам Windows не модульная система?

mdw>А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)

S>Допустим, написал я свой драйвер файловой системы — реализация никуда не
S>экспортируется, интерфейс к новой файловой системе предоставляется все теми
S>же CreateFile/WriteFile/ReadFile. Чем не компонента?

SG>> Таким образом, модули общаются между собой передавая друг другу не сами
SG>> объекты, а полиморфные переменные связанные с этими объектами.

Sergey>Этому условию замечательно соответсвуют оконная подсистема виндов, API
Sergey>работы с файлами и куча всего еще. В роли "полиморфной переменной" в этом
Sergey>случае выступают HWND и HANDLE.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...

Думаю, что лучше будет завести новую ветку форума для обсуждения этих вопросов.

Итак, что же такое модульная/компонентная система с точки зрения научного программирования? В обычном житейском смысле любая система состоящая из частей может быть названа модульной или компонентной, а любая ее часть, стало быть, будет модулем или компонентом. В обычном житейском смысле модуль или компонент это какая-то часть целого. Колесо — часть автомобиля, то есть в житейском смысле это его компонент. Руки и ноги — часть человека, в житейском смысле, значит, компоненты. Если, по аналогии с житейским смыслом, любую часть большой программы называть модулем или компонентом, то получится бардак. Все будут говорить что их системы являются модульными или компонентными, но все под этими терминами будут понимать что-то свое, например, всего лишь то что их системы состоят из частей. В программировании нужны более точные понятия модульности и компонентности.

Попытаюсь дать понятие модульной системы.

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

Почему Виндос с Юниксом не модульные — да потому что разные их части выполняются в разных средах исполнения — это не гомогенные, а гетерогенные системы. В тоже самое время Оберон системы являются именно модульными потому что они устроены "гомогенным способом": поверх железа работает среда исполнения в которой выполняются модули системы, причем между модулями, собственно, самой операционки и модулями приложений пользователя, с точки зрения среды исполнения, нет никакой разницы. В Виндосе же, поверх железа стоит ядро операционки, а среды исполнения Win32, DOS, COM и т.д. стоят поверх ядра. Драйверы работают в режиме ядра практически не имея никакой среды исполнения (именно отсутствие среды исполнения заставляет писать драйверы под Виндос на Си, а не на Си++ т.к. для работы программ написанных на Си++, как и для работы любых других программ написанных на объектно ориентированных языках, неоходима среда исполнения Runtime system).

Теперь попытаюсь дать понятие компонентной системы.

Компонентная система — это объектно ориентированная модульная система.

Компонентная система = Модульная система + ООП.

Компонентная система состоит только из модулей и больше не из чего не состоит. Объекты создаются внутри модулей. Модули общаются друг с другом передавая друг другу объекты, но не просто сами объекты, а полиморфные переменные ассоциированные с объектами. Модули компонентной системы называются компонентами.

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

На этом можно было бы и закончить, но дело в том что скрещивание модульности и ООП не проходит без последствий. Есть несколько ограничений накладываемых на компонентные системы:

Следствие 1
Не все ООП может быть тривиально "засунуто" в рамки модульных систем. Например, в ООП есть возможность строить гигантские иерархии наследования классов. С учетом модульности, все эти иерархии должны быть инкапсулированы внутри модулей. Межмодульное наследование, т.е. когда "половина" класса дана в одном модуле, а другая "половина" класса дана в другом модуле — это такая опасная штука, что от нее в рамках парадигмы КОП (Компонентно ориентированное программирование) просто напросто отказываются. Наследоваться можно, но только для классов находящихся внутри одного модуля. Межмодульное наследование возможно только для абстрактных классов, то есть это даже и не наследование, а реализация интерфейса.

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

Следствие 3
Поскольку между модулями операционной системы и модулями пользователя с точки зрения среды исполнения нет ни какой разницы, то вся ответственность за безопасность и надежность системы накладывается именно на среду исполнения. Это означает что среда исполнения всегда должна проверять индексы массивов на предмет выхода за границы массива, всегда проверять арифметические переполнения, разрешать только "правильные" приведения типов объектов и т.д.

Следствия из следствия 3
3.1 Программы должны быть написаны на безопасных модульных языках программирования. Так как в опасных, например на Си или Си++ невозможно заставить среду исполнения пресекать ошибки переполнения буфера или некорректного приведения типов или разыменования повисших или каких либо других не корректных указателей. Компонентные программы, например, можно писать на Оберонах.
3.2 Поскольку безопасность системы гарантируется самой средой исполнения, то можно использовать всего лишь одно единственное адресное пространство. Это очень сильно повышает производительность. Повышает гораздо сильнее чем ее снижает постоянные проверки индексов... Например, в Aos BlueBottle написанной на Active Oberon скорость переключения между процессами примерно в 40 раз выше чем скорость переключения между процессами в Юниксе. Вызов системной функции для пользователя не является долгим, так как не надо долго ожидать переключения в режим ядра, а является таким же быстрым как вызов любой другой функции — вспомните, что для среды исполнения нет разницы между модулями самой операционки и модулями пользователя.

Принимая во внимание вышеизложенное, десяток лет назад (Клеменсом Шиперски) была сформулирована Компонентно ориентированная парадигма программирования:

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

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

Hello, S.Yu.Gubanov!
You wrote on Tue, 24 Aug 2004 07:53:21 GMT:

SG> Думаю, что лучше будет завести новую ветку форума для обсуждения этих
SG> вопросов.

SG> Попытаюсь дать понятие модульной системы.

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

Как нетрудно видеть, это требование бессмысленно, поскольку можно систему
разбить на гомогенные подсистемы и объявить модульной подсистему либо
отнести все не удовлетворяющие этому требованию части системы к среде
исполнения. Так, подсистемы ввода-вывода и управления памятью windows
являются частью среды исполнения для модульной оконной подсистемы windows.
Ну и, наконец, само требование гомогенности притянуто за уши.

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

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

SG> Почему Виндос с Юниксом не модульные — да потому что разные их части
SG> выполняются в разных средах исполнения — это не гомогенные, а
SG> гетерогенные системы. В тоже самое время Оберон системы являются именно
SG> модульными потому что они устроены "гомогенным способом": поверх железа
SG> работает среда исполнения в которой выполняются модули системы, причем
SG> между модулями, собственно, самой операционки и модулями приложений
SG> пользователя, с точки зрения среды исполнения, нет никакой разницы. В
SG> Виндосе же, поверх железа стоит ядро операционки, а среды исполнения
SG> Win32, DOS, COM и т.д. стоят поверх ядра.

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

SG> Драйверы работают в режиме ядра практически не имея никакой среды
SG> исполнения (именно отсутствие среды исполнения заставляет писать
SG> драйверы под Виндос на Си, а не на Си++ т.к. для работы программ
SG> написанных на Си++, как и для работы любых других программ написанных
SG> на объектно ориентированных языках, неоходима среда исполнения Runtime
SG> system).

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

SG> Теперь попытаюсь дать понятие компонентной системы.

SG> Компонентная система — это объектно ориентированная модульная система.
SG>

SG> Компонентная система = Модульная система + ООП.

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

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

SG> Объекты создаются внутри модулей. Модули общаются друг с другом
SG> передавая друг другу объекты, но не просто сами объекты, а полиморфные
SG> переменные ассоциированные с объектами.

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

SG> Виндос с Юниксом — не компонентные еще и потому что мало того что они
SG> не модульные, но они еще и не объектно ориентированные.

Файловый ввод/вывод и оконная подсистема в windows —
объектно-ориентированные. Если это тебе не очевидно, могу объяснить.

SG> Следствие 1

Следствие из чего?

SG> находящихся внутри одного модуля. Межмодульное наследование возможно
SG> только для абстрактных классов, то есть это даже и не наследование, а
SG> реализация интерфейса.

Дай определение абстрактного класса.

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

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

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

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

SG> 3.1 Программы должны быть написаны на безопасных модульных
SG> языках программирования. Так как в опасных, например на Си или Си++
SG> невозможно заставить среду исполнения пресекать ошибки переполнения
SG> буфера или некорректного приведения типов или разыменования повисших
SG> или каких либо других не корректных указателей.

Это ты Бабаяну расскажи

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

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

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

With best regards, Sergey.

Здравствуйте, 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.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

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

Мама родная... Что же вы всё в кучу свалили и при том совершенно неверную. Абстрактный тип данных, интерфейс и абстрактный класс — это всё разные вещи! С точки зрения ООП абстрактный тип данных — это любой тип данных.
1) С позиции именно типов данных ООП разделяет их на: абстрактные и физические. Причём над любым физическим типом данных лежит абстрактный тип данных, но не под любым абстрактным типом лежит физический. Области применения этих терминов можно условно разделить следующим образом: физический размер переменной — это в ведении физического типа данных, что можно делать с переменной (разрешение проблемы классификации выражений и проверка типов) — это в ведении абстрактного типа данных.
2) Интерфейс — (понятия интерфейсный тип в ООП вообще отсутствует) понятие, реализующее принцип инкапсуляции, определяет контракт для доступа к объекту: набор требований к клиенту и обязательств объекта.
3) Абстрактный класс — понятие не имеющее никакого отношения к ООП, это один из способов реализации интерфейса в некоторых языках программирования.
Понятия статического и динамического типов в ООП также не существует — это термины, относящиеся исключительно к конкретным реализациям ООП в некоторых языках программирования. Они имеют смысл только там, где реализация ООП тесно связана с понятиями класса, наследования, статическая типизация — это справедливо не для всех языков.

А вот что такое полиморфная переменная — это для меня действительно загадка...

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

Это всё термины языка C++ (ну или C#), а не ООП и тем более КОП в целом. Если взять такие языки, как Object Prolog или Self, ваше определение не имеет никакого смысла (там вообще нет понятия класса, а следовательно и абстрактного класса и тем более статического типа).

Вы уж извините, я не очень силён в КОП и Оберон-системах, но в вопросах ООП немного разбираюсь...

Hello, S.Yu.Gubanov!
You wrote on Tue, 24 Aug 2004 09:53:04 GMT:

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

Откуда это требование вообще взялось и что дает его выполнение?

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

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

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

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

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

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

Оконная подсистема Виндов не расширяемы? Не смеши. Делаю свой контрол, кладу
его в myhexedit.dll. Любой желающий грузит myhexedit.dll, вызывает
CreateWindow("HEXEDIT", ....) и юзает мой контрол сколько влезет тем же
способом, что и обычный edit.

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

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

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

Ну тогда зачем было писать "Компонентная система состоит только из модулей и
больше не из чего не состоит"? Поаккуратнее с формулировочками, пожалуйста.

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

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

Статический тип, динамический тип, указатель, абстрактный класс — понятия
некоторых языков программирования. Поэтому не следует употреблять эти
понятия при обсуждении парадигм программирования. Либо следует доказать
сначала, что языки, лишенные этих понятий, не могут использоваться согласно
обсуждаемой парадигме. Это раз.
Полиморфное поведение объекта можно реализовать не отдавая наружу
указатели — это два.

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

Еще раз повторяю — оконная подсистема в windows имеет объектно
ориентированный интерфейс. Полностью. Что там внутри — никого не касается.

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

Неа. Не диктует. Ты еще одно требование забыл.

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

Может не быть ни "полиморфных переменных", ни статических типов, а интерфейс
объекта задаваться функциями. И при этом все равно можно реализовать
полиморфное поведение объектов, наследование и инкапсуляцию.

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

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

Очень просто — я возложу задачу удаления объектов, на которые есть внешние
ссылки, на пользователя этих объектов. Поскольку алгоритм программы жестко
зависит от входных данных, эта задача решаема.

SG> Как Вы сможете внутри своего модуля расставить на каждый NEW(x)
SG> соответсвтвующий ему DISPOSE(x)?

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

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

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

SG> Вы думаете что пошутили, да?
Нет, конечно.

SG> Как бы не так! В будущем оберонистая Runtime system разумеется будет
SG> реализована в железе.

Все это уже реализовано в "Эльбрусе". А вот Оберон вряд ли кто станет в
железе реализовывать.

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

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

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

SG> Опять Вы думаете что пошутили, да?

Нет, конечно. Я думаю, что ты неточен в формулировках.

With best regards, Sergey.

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


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

S>Откуда это требование вообще взялось и что дает его выполнение?

Это не требование. Просто есть такие системы и они носят название модульных систем. Остальные системы не могут называться модульными системами. Дает это — открытость и расширяемость системы самым что ни на есть дешевым способом (дешевле не бывает).

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

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

При чем тут состав загружаемых модулей!!! Слинковано — означает что все адреса процедур экспортируемых модулями стали известны. Пусть есть два модуля M1 и М2, внутри модуля М1 вызываем процедуру P2 из модуля М2

M2.P2();

в момент компиляции адрес процедуры не известен. Адрес выставляется линковщиком во время линковки. Модульные системы линкуются динамически. А полностью скомпилированная и слинкованная программа — это частный случай.

S>Оконная подсистема Виндов не расширяемы?
...
S>Еще раз повторяю — оконная подсистема в windows имеет объектно
S>ориентированный интерфейс. Полностью. Что там внутри — никого не касается.

Далась Вам эта оконная подсистема... Я говорил про всю Винду в целом, а не про ее конкретные подсистемы.


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

S>Очень просто — я возложу задачу удаления объектов, на которые есть внешние
S>ссылки, на пользователя этих объектов.

А я разьве сказал что Вы пользователю отдадите объект? Не-е-ет, по условию задачи объект останется Ваш, просто Вы внешнему миру сообщите его адрес. Ну что, задачка статически не разрешима? Решить ее можно только динамически, во время работы системы? То есть нужен сборщик мусора?

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

MN>А вот что такое полиморфная переменная — это для меня действительно загадка...

Ну, тогда, полиморфная переменная — это переменная полиморфного типа. А полиморфные типы в разных языках программирования разные...

В Delphi, Java, C# полиморфныей тип это — INTERFACE
В С++ — это указатель на объект класса у которого все функции виртуальные и абстрактные.
В Component Pascal (Oberon №3) полиморфный тип это POINTER TO ABSTRACT RECORD

Так понятнее?

Hello, S.Yu.Gubanov!
You wrote on Tue, 24 Aug 2004 12:13:48 GMT:

S>> Откуда это требование вообще взялось и что дает его выполнение?

SG> Это не требование. Просто есть такие системы и они носят название
SG> модульных систем.

Это общепринятое определение?

SG> Остальные системы не могут называться модульными системами.

Почему?

SG> Дает это -
SG> открытость и расширяемость системы самым что ни на есть дешевым
SG> способом (дешевле не бывает).

Неочевидно.

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

SG> При чем тут состав загружаемых модулей!!!

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

SG> линковщиком во время линковки. Модульные системы линкуются динамически.

Так линкуются динамически или их модули могут загружаться в произвольный
момент времени? Потому что это разные вещи.

SG> А полностью скомпилированная и слинкованная программа — это частный
SG> случай.

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

SG> Далась Вам эта оконная подсистема... Я говорил про всю Винду в целом, а
SG> не про ее конкретные подсистемы.

А я тебе приводил пример системы, которая по твоим критериям может считаться
компонентной. И ты вроде бы с моим утверждением не согласился.

SG> А я разьве сказал что Вы пользователю отдадите объект? Не-е-ет, по
SG> условию задачи объект останется Ваш, просто Вы внешнему миру сообщите
SG> его адрес.

А какая разница?

SG> Ну что, задачка статически не разрешима?

Статически — нет.

SG> Решить ее можно только
SG> динамически, во время работы системы?

Да.

SG> То есть нужен сборщик мусора?

Нет, не обязательно.

With best regards, Sergey.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А я разьве сказал что Вы пользователю отдадите объект? Не-е-ет, по условию задачи объект останется Ваш, просто Вы внешнему миру сообщите его адрес. Ну что, задачка статически не разрешима? Решить ее можно только динамически, во время работы системы? То есть нужен сборщик мусора?

1) А как локальный сборщик мусора определит, что мир на удалённой машине больше не использует данный объект? Выходит что и со сборщиком мусора задача не разрешима, если на сцену выходят распределённые архитектуры?
2) И почему это объект остаётся мой? А на кой чёрт он мне сдался? Если я его использую, то я такой же клиент своего объекта и как только он мне больше не будет нужен я сообщу об этом ему или какой-нть подсистеме, которая отвесает за уничтожение не нужных объектов. Как только объект больше не нужен никому он будет уничтожен — даже банальный подсчёт ссылок иногда для этого катит.
3) Мы тут все говорим о высоких абстракциях в стиле ООП и КОП, тогда почему я должен возвращать адрес объекта. Вы же сами твердили о полиморфных переменных. Может быть с адресом эту проблему действительно сложно решить без GC — уж больно кроявая архитектура выходит, но вот с объектом — уже проще.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Mr. None, Вы писали:

MN>>А вот что такое полиморфная переменная — это для меня действительно загадка...

SYG>Ну, тогда, полиморфная переменная — это переменная полиморфного типа. А полиморфные типы в разных языках программирования разные...

SYG>В Delphi, Java, C# полиморфныей тип это — INTERFACE
SYG>В С++ — это указатель на объект класса у которого все функции виртуальные и абстрактные.
SYG>В Component Pascal (Oberon №3) полиморфный тип это POINTER TO ABSTRACT RECORD

SYG>Так понятнее?

И опять мимо... Полиморфных типов не бывает вовсе, бывают полиморфные объекты — это объекты обладающие множеством типов.

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

MN>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>Здравствуйте, Mr. None, Вы писали:

MN>>>А вот что такое полиморфная переменная — это для меня действительно загадка...

SYG>>Ну, тогда, полиморфная переменная — это переменная полиморфного типа. А полиморфные типы в разных языках программирования разные...

SYG>>В Delphi, Java, C# полиморфныей тип это — INTERFACE
SYG>>В С++ — это указатель на объект класса у которого все функции виртуальные и абстрактные.
SYG>>В Component Pascal (Oberon №3) полиморфный тип это POINTER TO ABSTRACT RECORD

SYG>>Так понятнее?

MN>И опять мимо... Полиморфных типов не бывает вовсе, бывают полиморфные объекты — это объекты обладающие множеством типов.

Сорри немного ошибся — домой тороплюсь. Но сути это не меняет.
Правильно так:
полиморфных типов не бывает вовсе, полиморфизм — это свойство различных объектов по разному реализовывать требования единого контракта.

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

SG>> Это не требование. Просто есть такие системы и они носят название
SG>> модульных систем.

S>Это общепринятое определение?

Вроде того. По крайней мере в докторской диссертации Питера Мюллера под модульными системами подразумевают именно то определение которое я тут пытался сформулировать. Мюллер — один из создателей Aos BlueBottle http://www.cs.inf.ethz.ch/~muller/

SG>> Остальные системы не могут называться модульными системами.
S>Почему?
Должна же быть ясность в определениях?


S>Так линкуются динамически или их модули могут загружаться в произвольный
S>момент времени? Потому что это разные вещи.

Вот когда мы пытаемся выполнить процедуру Р2 из модуля М2:

М2.Р2();

но модуль М2 еще не загружен в память, вот тогда, среда исполнения загружает модуль М2 в память, после загрузки его в память адрес процедуры Р2 становится известным (то есть произошла динамическая линковка только что загруженного модуля). После этого процедура Р2 запускается на выполнение. Если же модуль М2 уже был загружен ранее, то код

М2.Р2();

просто сразу запускает процедуру Р2 на выполнение.

S>А я тебе приводил пример системы, которая по твоим критериям может считаться
S>компонентной. И ты вроде бы с моим утверждением не согласился.

Это с драйверами Виндос? Или с оконной подсистемой? Я не соглашался с тем, что они являются компонентами Виндоса. Частями Виндоса они являются, а для компонентов есть другой смысл. В чем отличие просто "части" от "компонента" я и сформулировал в корне этой ветки форума.

SG>> Решить ее можно только
SG>> динамически, во время работы системы?
S>Да.
SG>> То есть нужен сборщик мусора?
S>Нет, не обязательно.

Но разьве та штуковина, которая будет выполнять эту работу динамически, разьве она не называется сборщиком мусора?

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

MN>Правильно так:
MN>полиморфных типов не бывает вовсе, полиморфизм — это свойство различных объектов по разному реализовывать требования единого контракта.

Ну вот, этот самый контракт в конкретном языке программирования как-то записывается! В одном языке для этого используют одно, а в другом другое.

Например, тип Storable — определенный ниже:

TYPE
    Storable = INTERFACE ['{95125314-4465-4B04-A4EC-8271DC8E940D}']
      PROCEDURE Externalize(CONST Writer: Writer);
      PROCEDURE Internalize(CONST Reader: Reader);
    END;

определяет контракт.

VAR
  x: Storable;
  t: OtherPolymorficType;
BEGIN
  LoadStoreFromFile(x, 'aaa.db');
  t := x AS OtherPolymorficType;
  t.DoSmth();
  SaveStoreIntoFile(t, 'bbb.db');

x и t — полиморфные переменные.

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

MN>1) А как локальный сборщик мусора определит, что мир на удалённой машине больше не использует данный объект? Выходит что и со сборщиком мусора задача не разрешима, если на сцену выходят распределённые архитектуры?

К сожалению, на удаленные машины локальный сборщик мусора не покушается. Есть такая проблема.

MN>2) И почему это объект остаётся мой? А на кой чёрт он мне сдался?

А это для примера. Я же сказал, что в общем случае нужен сборщик мусора, хотя в конкретных частных случаях можно обойтись и без него. Если кто-то не согласен, что в общем случае GC все-таки нужен, то пусть сначала решит в общем виде этот пример.


MN>3) Мы тут все говорим о высоких абстракциях в стиле ООП и КОП, тогда почему я должен возвращать адрес объекта.

Ну это я заболтался просто, разумеется я всегда имел в виду не адреса объектов, а полиморфные переменные связанные с этими объектами.

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

MN>Правильно так:
MN>полиморфных типов не бывает вовсе, полиморфизм — это свойство различных объектов по разному реализовывать требования единого контракта.

Верно, а полиморфная переменная — это как раз та переменная которая ссылается на один из этих самых объектов, которые по разному реализовали контракт.

Мы работаем не с самими объектами, а с полиморфными переменными.

Если бы мы имели непосредственно сам объект, то мы бы уже точно наверняка знали как именно он реализовал контракт. Нам в этом интереса нет. А вот когда у нас есть полиморфная переменная, то мы обладаем информацией о том что объект на который она ссылается этот контракт реализовывает, но как именно — это другой вопрос. Вот это интересно.

Полиморфная переменная есть переменная полиморфного типа (не пугайтесь, это обычная тавтология). А полиморфный тип — это, стало быть, всего лишь иное обозвание контракта (интерфейса).

Hello, S.Yu.Gubanov!
You wrote on Tue, 24 Aug 2004 12:51:35 GMT:

SG>>> Это не требование. Просто есть такие системы и они носят название
SG>>> модульных систем.

S>> Это общепринятое определение?

SG> Вроде того. По крайней мере в докторской диссертации Питера Мюллера под
SG> модульными системами подразумевают именно то определение которое я тут
SG> пытался сформулировать.

В диссертации Питера Мюллера это называется не модульными, а extensible
системами. Причем основным критерием
strong division между юзерскими/системными модулями он полагает адресные
пространства. Честно говоря, это тоже фиговое определение, потому что тогда
Novell NetWare 3.1 вполне попадает под определение extensible систем — там
для всех задач одно адресное пространство

S>> Так линкуются динамически или их модули могут загружаться в
S>> произвольный момент времени? Потому что это разные вещи.

SG> Вот когда мы пытаемся выполнить процедуру Р2 из модуля М2:
SG>

М2.Р2();

SG> но модуль М2 еще не загружен в память, вот тогда, среда исполнения
SG> загружает модуль М2 в память, после загрузки его в память адрес
SG> процедуры Р2 становится известным (то есть произошла динамическая
SG> линковка только что загруженного модуля). После этого процедура Р2
SG> запускается на выполнение. Если же модуль М2 уже был загружен ранее, то
SG> код

М2.Р2();

SG> просто сразу запускает процедуру Р2 на выполнение.

А такой сценарий — система сразу грузит все свои модули в память, а адреса
процедур определяет по мере необходимости, удовлетворяет твоему определению?
Или такой — система сразу грузит все свои модули в память, а адреса процедур
модули регистрируют сразу после загрузки.

S>> А я тебе приводил пример системы, которая по твоим критериям может
S>> считаться компонентной. И ты вроде бы с моим утверждением не
S>> согласился.

SG> Это с драйверами Виндос? Или с оконной подсистемой?

Подсиситема файлового ввода/вывода (или графического вывода, например) и
оконная подсистема.

SG> Я не соглашался с тем, что они являются компонентами Виндоса.

А я не утверждал, что они являются компонентами Виндоса. Я утверждал, что
согласно твоему определению они сами являются модульными.

SG> Частями
SG> Виндоса они являются, а для компонентов есть другой смысл. В чем
SG> отличие просто "части" от "компонента" я и сформулировал в корне этой
SG> ветки форума.

Ты его фигово сформулировал, о чем и спич. Я, собственно, не пытаюсь
доказать, что они являются компонентными — я утверждаю, что согласно
твоему определению, они являются компонентными. Т.е., есть два
варианта — либо они на самом деле являются компонентными, либо ты дал
неправильное определение.

SG>>> Решить ее можно только
SG>>> динамически, во время работы системы?
S>> Да.
SG>>> То есть нужен сборщик мусора?
S>> Нет, не обязательно.

SG> Но разьве та штуковина, которая будет выполнять эту работу динамически,
SG> разьве она не называется сборщиком мусора?

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

With best regards, Sergey.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Итак, что же такое модульная/компонентная система с точки зрения научного программирования?

Это что ещё за зверь такой?

SYG>Попытаюсь дать понятие модульной системы.

А, собственно, почему вы навязываете свои определения?

SYG>Программная система состоящая из нескольких программных частей называется модульной, а ее части называются модулями, если все ее части функционируют в одной и той же среде исполнения и у нее нет никаких других частей кроме этих. Причем, среда исполнения может динамически загружать и выгружать части системы. И еще, для среды исполнения все части системы, то есть все модули, являются совершенно равноправными и эквивалентными, то есть среда исполнения не выделяет какие-либо модули по какому-либо признаку среди других модулей. Так сказать — гомогенная среда.

Application layer в Виндах подходит под это определение, поскольку вы можете подгружать и выгружать ddl-ки.

SYG>Почему Виндос с Юниксом не модульные — да потому что разные их части выполняются в разных средах исполнения — это не гомогенные, а гетерогенные системы.

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

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

А чем это отличается от DOS-а или vxWorks?

SYG>В Виндосе же, поверх железа стоит ядро операционки, а среды исполнения Win32, DOS, COM и т.д. стоят поверх ядра.

COM это не среда исполнения.

SYG>Драйверы работают в режиме ядра практически не имея никакой среды исполнения (именно отсутствие среды исполнения заставляет писать драйверы под Виндос на Си, а не на Си++ т.к. для работы программ написанных на Си++, как и для работы любых других программ написанных на объектно ориентированных языках, неоходима среда исполнения Runtime system).

Ну надо же. А я писал драйвера на С++. Вы бы что ли познакомились с предметом, прежде чем о нем рассуждать.

SYG>Теперь попытаюсь дать понятие компонентной системы.

SYG>Компонентная система — это объектно ориентированная модульная система.
SYG>

SYG>Компонентная система = Модульная система + ООП.

SYG>Компонентная система состоит только из модулей и больше не из чего не состоит. Объекты создаются внутри модулей. Модули общаются друг с другом передавая друг другу объекты, но не просто сами объекты, а полиморфные переменные ассоциированные с объектами. Модули компонентной системы называются компонентами.

SYG>Виндос с Юниксом — не компонентные еще и потому что мало того что они не модульные, но они еще и не объектно ориентированные.

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

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Верно, а полиморфная переменная — это как раз та переменная которая ссылается на один из этих самых объектов, которые по разному реализовали контракт.

SYG>Мы работаем не с самими объектами, а с полиморфными переменными.

Мы работаем именно с объектами. В отношении ООП в общем случае имеет смысл лишь понятие объекта, но не переменной. Потому как не во всех языках, реализующих объектно-ориентированную парадигму, существуют понятия типов и переменных. Пример: группа язков Object Prolog, там объект представляется как процесс бесконечного вычисления некого правила. Опа! Не спрашивайте как это — я сам плохо понимаю .

SYG>Если бы мы имели непосредственно сам объект, то мы бы уже точно наверняка знали как именно он реализовал контракт. Нам в этом интереса нет. А вот когда у нас есть полиморфная переменная, то мы обладаем информацией о том что объект на который она ссылается этот контракт реализовывает, но как именно — это другой вопрос. Вот это интересно.

Не правда. Вспомним азы: объект — это чёрный ящик, обладающий состоянием и "поведением", причём о внутренней реализации объекта мы ничего не знаем. Это в общем виде. А вот в виде чего представлен доступк к объекту? В виде переменной, указателя, ссылки, некой абстракции, блока памяти или бесконечного процесса вычисления (см. выше) — это уже детали реализации в конкретных языках программирования. Даже в стане процедурных языков нет единого стиля: в шарпе и джаве — это всегда ссылка; в плюсах — переменная, указатель или ссылка; в бэйсике — только переменная (кажись, могу ошибаться).

SYG>Полиморфная переменная есть переменная полиморфного типа (не пугайтесь, это обычная тавтология). А полиморфный тип — это, стало быть, всего лишь иное обозвание контракта (интерфейса).

Это ваша собственная интерпретация и ваши собственные названия ни как не совпадающие с общепринятыми. Я уже объяснил почему.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Mr. None, Вы писали:

MN>>2) И почему это объект остаётся мой? А на кой чёрт он мне сдался?

SYG>А это для примера. Я же сказал, что в общем случае нужен сборщик мусора, хотя в конкретных частных случаях можно обойтись и без него. Если кто-то не согласен, что в общем случае GC все-таки нужен, то пусть сначала решит в общем виде этот пример.

Решение уже было предложено:

Очень просто — я возложу задачу удаления объектов, на которые есть внешние
ссылки, на пользователя этих объектов. Поскольку алгоритм программы жестко
зависит от входных данных, эта задача решаема.

(C) Sergey.

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

SYG>Ну это я заболтался просто, разумеется я всегда имел в виду не адреса объектов, а полиморфные переменные связанные с этими объектами.

Нет никаких полиморфных переменных в рамках ООП, хотя бы потому что не все объектно-ориентированные языки имеют понятие переменная, есть объекты и не надо изобретать собственные термины.