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

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>Ну это я заболтался просто, разумеется я всегда имел в виду не адреса объектов, а полиморфные переменные связанные с этими объектами.

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

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

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

Вообще бывают. Например в SDL, но это не язык программирования.

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

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

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

_O_>Вообще бывают. Например в SDL, но это не язык программирования.

Речь идён конкретно об Объектно Ориентированной Парадигме. В её рамках такого понятия как полиморфный тип не сущетсвует.

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

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

Ш>Это называется изоляцией компонент системы. Которая совершенно необходима для создания устойчивых операционных систем. А иначе сбой в одном модуле может легко положить всю систему.
Почему же сразу "совершенно необходима"? Сбой в одном модуле приводит всего-лишь к "горячей" перезагрузке модуля. А вот, например, в Zonnon-е, можно сделать так что сбой в активном объекте будет приводить к перезапуску активного объекта с сохранением всех его данных.

Ш>COM это не среда исполнения.
Возможно и не среда, но я в книжках читал что среда, спорить не буду — по большому счету мне это без разницы...

Ш>Ну надо же. А я писал драйвера на С++. Вы бы что ли познакомились с предметом, прежде чем о нем рассуждать.
Драйверы для ядра виндос? И можно было пользоваться всеми фишками С++? Поздравляю Вас, ибо в тех книжках, которые я читал было написано, что это делать можно только на Си, так как только Си может работать непосредственно поверх железа, а для Си++ нужна какая-никакая, а всетаки runtime system. До чего дошел прогресс.

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

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

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

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

В отсталых языках может и нету, а вообще есть. Посмотрим на код:

TYPE
  Polymorfic = INTERFACE
    PROCEDURE DoSmth();
  END;

  ObjectA = CLASS (TIntrefacedObject, Polymorfic)
    PROCEDURE DoSmth();
  END;

  ObjectB = CLASS (TIntrefacedObject, Polymorfic)
    PROCEDURE DoSmth();
  END;

//----------------------------------------------------------------------------

PROCEDURE ObjectA.DoSmth();
BEGIN
  //...
END;

//----------------------------------------------------------------------------

PROCEDURE ObjectB.DoSmth();
BEGIN
  //...
END;

//----------------------------------------------------------------------------

VAR
  p: Polymorfic;
  a: ObjectA;
  b: ObjectB;
BEGIN
  p := NIL;

  a := ObjectA.Create();
  // a - это объект типа "ObjectA"

  b := ObjectB.Create();
  // b - это объект типа "ObjectB"

  p := a;
  p.DoSmth();
  // p - это не объект, p - это полиморфная переменная связанная с объектом "a" типа "ObjectA"

  p := b;
  p.DoSmth();
  // p - это не объект, p - это полиморфная переменная связанная с объектом "b" типа "ObjectB"

Обратите внимание на то что процедуры

PROCEDURE ObjectA.DoSmth();
PROCEDURE ObjectB.DoSmth();

НЕ виртуальные! Это самые обычные объектные процедуры. Еще обратите внимание на то что типы ObjectA и ObjectB не связаны друг с другом никаким отношением наследования, то есть переменной типа ObjectA нельзя присвоить значение переменной типа ObjectB и наоборот.

a := b; // ОШИБКА
b := a; // ОШИБКА
a := p; // ОШИБКА
b := p; // ОШИБКА
p := a; // правильно
p := b; // правильно

Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

P. S.
Кстати в Си++ вместо INTERFACE использовался бы клас с чисто виртуальной функцией и множественное наследование. Это примерно то что нужно, но все-таки не совсем то. Дело в том что в Си++ тогда возможно присваивание a := xxxxxxxx_cast<ObjectA>(p) в том случае если "p" ссылается на объект "a". А для полиморфной переменной подобные присваивания просто бессмысленны. Нельзя из недр полиморфной переменной вытащить сам объект с которым она была связана.

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

SYG>Почему же сразу "совершенно необходима"? Сбой в одном модуле приводит всего-лишь к "горячей" перезагрузке модуля. А вот, например, в Zonnon-е, можно сделать так что сбой в активном объекте будет приводить к перезапуску активного объекта с сохранением всех его данных.

Как это? Если это был модуль хранилища данных и в результате сбоя он запортил данные в нем хранимые. Как это ты его перезагрузишь с сохранением данных? А если это был модуль управления потоками?

SYG>Драйверы для ядра виндос? И можно было пользоваться всеми фишками С++? Поздравляю Вас, ибо в тех книжках, которые я читал было написано, что это делать можно только на Си, так как только Си может работать непосредственно поверх железа, а для Си++ нужна какая-никакая, а всетаки runtime system. До чего дошел прогресс.

Да? В этом смысле и С и С++ одинаковые. Из необходимых вещей есть только загрузчик, а runtime — это стандартные библиотечные функции. Хочешь — юзай, не хочешь — не юзай. Но и в С, и в С++.

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

S>либо ты дал неправильное определение.

Подумаю, потом, может дам определение получше.

S> сборщик мусора не обязан быть встроен в систему.

А куда он должен быть встроен?
Есть среда исполнения и есть куча равноправных модулей. Объект созданный каким-то одним модулем, в общем случае, может быть известен всем остальным модулям. Значит штуковина следящая за этим объектом должна быть вне этих модулей, но вне этих модулей есть только сама среда исполнения, значит сама среда исполнения должна заниматься сборкой мусора, в конце-концов именно среде исполнения лучше же видно кого можно убить, а кого еще нет; да и внутреннее устройство операции NEW(x) ведь именно средой исполнения обеспечивается...так пусть она и убивает.

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

SYG>В отсталых языках может и нету, а вообще есть.

Это как? Вот пример ОО языка Object Prolog, ну нету там переменных!!

SYG>

SYG>VAR
SYG>  p: Polymorfic;
SYG>  a: ObjectA;
SYG>  b: ObjectB;
SYG>BEGIN
SYG>  p := NIL;

SYG>  a := ObjectA.Create();
SYG>  // a - это объект типа "ObjectA"
a - это переменная типа ObjectA, в которую сохранён объект класса ObjectA, реализующего типы ObjectA и Polymorfic.

SYG>  b := ObjectB.Create();
SYG>  // b - это объект типа "ObjectB"
b - это переменная типа ObjectB, в которую сохранён объект класса ObjectB, реализующего типы ObjectB и Polymorfic.

SYG>  p := a;
SYG>  p.DoSmth();
SYG>  // p - это не объект, p - это полиморфная переменная связанная с объектом "a" типа "ObjectA"
p - это переменная типа Polymorfic, в которую сохранён объект класс ObjectA, реализующего типы ObjectA и Polymorfic.

SYG>  p := b;
SYG>  p.DoSmth();
SYG>  // p - это не объект, p - это полиморфная переменная связанная с объектом "b" типа "ObjectB"
p - это переменная типа Polymorfic, в которую сохранён объект класс ObjectB, реализующего типы ObjectB и Polymorfic.
SYG>

SYG>Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

Просто переменная такого-то типа.

SYG>P. S.
SYG>Кстати в Си++ вместо INTERFACE использовался бы клас с чисто виртуальной функцией и множественное наследование.

Я в курсе.

SYG>Это примерно то что нужно, но все-таки не совсем то. Дело в том что в Си++ тогда возможно присваивание a := dynamic_cast<ObjectA>(p) в том случае если "p" ссылается на объект "a". А для полиморфной переменной подобные присваивания просто бессмысленны. Нельзя из недр полиморфной переменной вытащить сам объект с которым она была связана.

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

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

L>Как это? Если это был модуль хранилища данных и в результате сбоя он запортил данные в нем хранимые. Как это ты его перезагрузишь с сохранением данных? А если это был модуль управления потоками?

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

Ну а если сбой был критичен для самой среды исполнения, тогда: "а смерть придет — помирать будем"; или Вы можете предложить что-то другое? Честь Вам тогда и хвала.

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 08:25:50 GMT:

S>> сборщик мусора не обязан быть встроен в систему.

SG> А куда он должен быть встроен?

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

SG> Есть среда исполнения и есть куча равноправных модулей. Объект
SG> созданный каким-то одним модулем, в общем случае, может быть известен
SG> всем остальным модулям. Значит штуковина следящая за этим объектом
SG> должна быть вне этих модулей,

Нет, она вполне может быть и в одном из этих модулей.

SG> в конце-концов
SG> именно среде исполнения лучше же видно кого можно убить, а кого еще
SG> нет;

Нет. Когда убивать объект, лучше всего знает владелец объекта.

SG>
да и внутреннее устройство операции NEW(x) ведь именно средой
SG> исполнения обеспечивается...так пусть она и убивает.



With best regards, Sergey.

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

SYG>>Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

MN>Просто переменная такого-то типа.

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

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

SYG>Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

А вам не кажется что фраза полиморфная переменная вообще звучит как масло масляное. Если вдаваться в философствования, то любая переменная полиморфна.
Что такое полиморфизм — многообразие. С точки зрения ООП полиморфизм, как я уже говорил, — это многообразие поведений при неизменном контракте. Можно говорить о полиморфизме объекта — это возможность объекта предоставлять различные реализации одного контракта при разных состояниях (пример GOF-паттерн State). Можно говорить и полиморфизме среды или системы — это когда среда предоставляет возможность различным объектам по разному реализовать один и тот же контракт.
Ключевым моментом полиморфизма является требование прозрачности реализаций для клиента. Это означает, что клиент может ничего не знать о том сколько объектов и как они реализуют данный контракт — все объекты должны одинаково испольнять контрактные обязательства. Переключение клиента с одной реализации контракта на другую не должно накладывать дополнительные требования на уже существующий код, корректно работающий в рамках установленного контракта.

Любая переменная определённого типа может принимать любые объекты того же типа, тем самым при сохранении контракта (тип переменной не меняется) её состояние и поведение может меняться. Итак имеем: для любой переменной справедливо свойство полиморфности .

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

S>Нет. Когда убивать объект, лучше всего знает владелец объекта.

Во-первых, в общем случае у объекта может не быть владельца.

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

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 08:52:02 GMT:

SG> Во-первых, в общем случае у объекта может не быть владельца.

Например?

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

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

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

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

With best regards, Sergey.

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

SYG>>Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

MN>А вам не кажется что фраза полиморфная переменная вообще звучит как масло масляное
....
MN>Любая переменная определённого типа может принимать любые объекты того же типа, тем самым при сохранении контракта (тип переменной не меняется) её состояние и поведение может меняться. Итак имеем: для любой переменной справедливо свойство полиморфности .

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

Вот тут полиморфная переменная "р" принимает любые объекты типа ObjectA

p := a; 
p := a1; 
p := a2;

Но еще она может принимать любые объекты типа ObjectB

p := b; 
p := b1; 
p := b2;

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

Конкретно в Delphi это реализуется так: там есть отдельно таблица виртуальных функций и есть отдельно таблица интерфейсов. Классы и Интерфейсы могут организовывать две независимые иерархии наследования.

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

SG>> Во-первых, в общем случае у объекта может не быть владельца.

S>Например?

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

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

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

SYG>>>Переменную "p" я называю термином "полиморфная переменная". А Вы как называете?

MN>>А вам не кажется что фраза полиморфная переменная вообще звучит как масло масляное
SYG>....
MN>>Любая переменная определённого типа может принимать любые объекты того же типа, тем самым при сохранении контракта (тип переменной не меняется) её состояние и поведение может меняться. Итак имеем: для любой переменной справедливо свойство полиморфности .

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

Вы сами себя слышите? Вы вообще в курсе что такое переменная, тип, интерфейс? Переменная определённого типа может принимать только значения данного типа и всё точка. Никаких "какого угодно типа лишь бы этот какой угодно тип имел определенный интерфейс". Тип не имеет интерфейса! Если под интерфейсом понимать чисто виртуальные классы, то они сами по себе являются типами (абстрактными типами данных). Точно так же на равне с ними абстрактными типами даных являются signed int или char*. И точно также интерфейсом для объекта-ядра ОС Windows является набор функций из WinAPI. Это первое.
Теперь второе про объект нельзя говорить, что он того или иного типа. Объект может быть определённого класса и реализовывать определённые типы — чувствуете разницу?

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

У типов нет интерфейса! В частном случае некоторые интерфейсы являются типами. Множество типов и мнжество интерфесов пересекаются и не более.

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

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

SG>>> Во-первых, в общем случае у объекта может не быть владельца.

S>>Например?

SYG>Есть, например, в моей проге объект хранящий кое какие данные, которые изменяются со временем. Другие объекты знают об этом объекте и время от времени обращаются к нему, чтобы считать новые данные. Ни кто из этих других объектов не является хозяином того объекта. Но никаким другим-передругим объектам нет вообще никакого дела до того первого объекта. Вот, такой вот он бесхозяйственный.

Кто-то должен был бы создать этот объект, вот тот кто его создал и является его владельцем. А объект, который как-то сам появился и что-то там себе делает — это баг или вирус, в любом случае он нафиг не нужен и если его не будет от этого никому плохо не станет. Даже "если звёзды зажикаются, значит это кому-то надо" (C) В. Маяковский, а уж про объекты я вообще молчу .

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 09:15:33 GMT:

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

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

With best regards, Sergey.

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

MN>Кто-то должен был бы создать этот объект, вот тот кто его создал и является его владельцем.

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

S>Ты их буквами обозначь и еще раз объясни, а то я не вполне понял, кто куда
S>лазит. Но на первый взгляд здесь хватит рефкаунтинга — хозяином является
S>совокупность пользователей.

Был объект "a" владеющий объектом "Data". Потом объект "а" поверхностно клонировали на объекты "a", "a1", "a2", "a3"..., но объект "Data" оставили в единственном экземпляре. Так что единственного хозяина у объекта "Data" больше нет.

Рефкаунта здесь действительно хватит, им-то я и пользуюсь.

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

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


MN>Речь идён конкретно об Объектно Ориентированной Парадигме. В её рамках такого понятия как полиморфный тип не сущетсвует.

В UML 2.0 тип может быть виртуальным и переопределяться в наследниках контейнера, содержащего данный тип.

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 09:49:41 GMT:

SG> Был объект "a" владеющий объектом "Data". Потом объект "а" поверхностно
SG> клонировали на объекты "a", "a1", "a2", "a3"..., но объект "Data"
SG> оставили в единственном экземпляре. Так что единственного хозяина у
SG> объекта "Data" больше нет.

SG> Рефкаунта здесь действительно хватит, им-то я и пользуюсь.

SG> Но в общем случае, когда возможны циклические ссылки, рефкаунт
SG> бессилен.

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

SG> Придется вручную реализовывать свой аналог GC, а не лучше ли было бы
SG> если бы он был внутрях среды исполнения?

Вопрос был не в том, лучше или не лучше, а в том, возможно или не
возможно.Чтобы решать вопрос, что лучше и что хуже, сначало надо
определиться с тем, что возможно, а что нет.

With best regards, Sergey.

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

SG>> Во-первых, в общем случае у объекта может не быть владельца.
S>Например?

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

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

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

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

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

При reference counting'е тоже не все гладко. Как правило, после введения такой фишки
в свой проект, приходится писать что-то вроде AutoPtr, чтобы не загромождать код
бесконечными AddRef и Release. Ньюансов, которые при этом могут возникнуть — сотни,
не все их сначала учтешь, а потом, когда программа начинает валиться с ошибкой доступа,
нужно очень много времени, что размотать эту цепочку присваиваний-переприсваиваний-копирований-удалений
с отслеживанием состояния счетчика привязок и обнаружить, что вот при такой особенной ситуации
происходит неправильное обновление счетчика привязок.

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

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

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

MN>Теперь второе про объект нельзя говорить, что он того или иного типа. Объект может быть определённого класса и реализовывать определённые типы — чувствуете разницу?

А класс (CLASS) — это значит больше не тип, да? А интерфейс (INTERFACE) — это тип или это что такое? Один объект реализовывает или все-таки весь класс данных объектов реализовывает какой-то интерфейс? Не забивайте себе голову. А знаете, вот например, в Оберонах вообще нет ни классов, ни интерфейсов и связанной с ними терминологической путанницы тоже нет; зато есть тип RECORD и понятие TYPE EXTENSION — расширение типа. И ничего — самые крутые языки. Есть тип запись RECORD, который может быть 1) обычным, 2) EXTENSIBLE, 3) ABSTRACT, 4) LIMITED. Если он EXTENSIBLE или ABSTRACT то его можно расширять (ну то есть как бы наследоваться). Если он ABSTRACT, то его переменных создать нельзя, а надо сначала определить новый тип — его расширение (потомок) и если он будет объявлен как не ABSTRACT, то переменные создавать можно будет. Если LIMITED — то переменные можно создавать только внутри модуля в котором этот тип определен.

Hello, Kh_Oleg!
You wrote on Wed, 25 Aug 2004 10:10:04 GMT:

SG>>> Во-первых, в общем случае у объекта может не быть владельца.
S>> Например?

KO> Например, у объекта, передающего аргументы от одного объекта другому
KO> при возникновении события.

Владелец меняется — сначала первый объект, потом второй.

KO> Или при возникновении исключительной ситуации.

Владелец — рантайм.

KO> Это все хорошо в теории и для относительно небольших программ. В очень
KO> больших сложных системах, с высокой степенью связности между
KO> подсистемами, правильное уничтожение объектов, причем в правильной
KO> последовательности, является огромной проблемой и источником
KO> трудноотлаживаемых ошибок. Я не спорю, что связность — это плохо, но не
KO> всегда удается "развязать" систему.

Речь шла о принципиальной возможности, а не о недостатках.

KO> Касательно ваших вариантов — первый вариант чреват неочевидностью
KO> (точнее плохой наглядностью) в том, кто должен получать оповещения и в
KO> каком порядке. Нужно сверхтщательно отслеживать свой код, чтобы не
KO> допустить зацикливания таких оповещений.

В результате чего программист наконец понимает, что же он такое написал

KO> При reference counting'е тоже не все гладко. Как правило, после
KO> введения такой фишки в свой проект, приходится писать что-то вроде
KO> AutoPtr, чтобы не загромождать код бесконечными AddRef и Release.

На практике — не приходится. Все уже давно написано.

KO> Третий вариант мне предстваляется просто частным решением проблемы,
KO> которое в некоторых случаях приемлемо, а в других — нет.

Сброщик мусора — такое же частное решение, которое в некоторых случаях
приемлемо, а в других — нет.

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

И позволяет обеспечить при этом жесткий реалтайм или детерминированное
поведение исполнительных механизмов

With best regards, Sergey.

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 10:24:15 GMT:

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

MN>> Теперь второе про объект нельзя говорить, что он того или иного типа.
MN>> Объект может быть определённого класса и реализовывать определённые
MN>> типы — чувствуете разницу?

SG> А класс (CLASS) — это значит больше не тип, да? А интерфейс (INTERFACE)
SG> — это тип или это что такое? Один объект реализовывает или
SG> все-таки весь класс данных объектов реализовывает какой-то интерфейс?
SG> Не забивайте себе голову.

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

With best regards, Sergey.

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

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


MN>>Речь идён конкретно об Объектно Ориентированной Парадигме. В её рамках такого понятия как полиморфный тип не сущетсвует.

_O_>В UML 2.0 тип может быть виртуальным и переопределяться в наследниках контейнера, содержащего данный тип.

Ах да, совсем забыл!!! А вот, например, в Delphi есть метаклассы — это типы переменные которых принимают значения самих классов объектов. Вот уж точно полиморфный-переполиморфный тип.

TYPE
  MyObject = CLASS
    CONSTRUCTOR New; VIRTUAL; // виртуальный конструктор
    //...
  END;
  
  OtherObject = CLASS (MyObject)
    CONSTRUCTOR New; OVERRIDE; // переопределение виртуального конструктора
    //..
  END;

  MyClass = CLASS OF MyObject;

VAR 
  x: MyObject;
  C: MyClass;
BEGIN
  C := OtherObject;
  x := C.New();
  // x - это переменная типа MyObject в которую записали значение переменной типа OtherObject

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

SG>>>> Во-первых, в общем случае у объекта может не быть владельца.
S>>> Например?

1. Например, у объекта, передающего аргументы от одного объекта другому
при возникновении события.
S>Владелец меняется — сначала первый объект, потом второй.

2. Или при возникновении исключительной ситуации.
S>Владелец — рантайм.

Кто в каждом из этих случаев должен удалять объект?

KO>> Это все хорошо в теории и для относительно небольших программ. В очень
KO>> больших сложных системах, с высокой степенью связности между
KO>> подсистемами, правильное уничтожение объектов, причем в правильной
KO>> последовательности, является огромной проблемой и источником
KO>> трудноотлаживаемых ошибок. Я не спорю, что связность — это плохо, но не
KO>> всегда удается "развязать" систему.

S>Речь шла о принципиальной возможности, а не о недостатках.
Принципиально много что возможно, даже взлом самых стойких алгоритмов шифрования.
Вопрос в стоимости.

KO>> Касательно ваших вариантов — первый вариант чреват неочевидностью
KO>> (точнее плохой наглядностью) в том, кто должен получать оповещения и в
KO>> каком порядке. Нужно сверхтщательно отслеживать свой код, чтобы не
KO>> допустить зацикливания таких оповещений.

S>В результате чего программист наконец понимает, что же он такое написал
Через два месяца отладки, безнадежно сорвав сроки релиза.


KO>> Третий вариант мне предстваляется просто частным решением проблемы,
KO>> которое в некоторых случаях приемлемо, а в других — нет.
S>Сброщик мусора — такое же частное решение, которое в некоторых случаях
S>приемлемо, а в других — нет.

В каких случаях GC неприемлем?

S>И позволяет обеспечить при этом жесткий реалтайм или детерминированное
S>поведение исполнительных механизмов


На самом деле, вопрос о необходимости такого детерминизма — это отдельная тема.

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

S>Объект, реализующий доступ к файлу в виндах —
S>он какого типа? А интерфейс к критической секции — это что, тип?

Винды не ОО ситема так что там фиг знает какого типа. А в ОО системах тип объектов известен. Я про файлы в ОО системах уже писал:
http://www.rsdn.ru/Forum/Message.aspx?mid=725451&amp;only=1

Автор: S.Yu.Gubanov
Дата: 19.07.04

Кроме того, представьте себе что файл — это персистентный объект. Тогда файловая система Вам больше не нужна, а нужна "всего лишь" Объектная СУБД. Когда-нибудь какую-нибудь объектную СУБД интегрирует внутрь какой-нибудь системы исполнения, вот будет крутизна...

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

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

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


SYG>Ах да, совсем забыл!!! А вот, например, в Delphi есть метаклассы — это типы переменные которых принимают значения самих классов объектов. Вот уж точно полиморфный-переполиморфный тип.

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

А полиморфный тип — это судя по всему нечто такое, что умеет менять свою структуру неким произвольным образом... То есть сегодня MyCleverInterface содержит функции fun1 и fun2, а завтра уже some_fun1, some_fun2 и some_fun3... Может и возможно такое, но только в какой-нибудь нечёткой логике, но никак ни в программировании, покрайней мере не в ООП.

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

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


MN>>Речь идён конкретно об Объектно Ориентированной Парадигме. В её рамках такого понятия как полиморфный тип не сущетсвует.

_O_>В UML 2.0 тип может быть виртуальным и переопределяться в наследниках контейнера, содержащего данный тип.

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

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

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

SG>>>>> Во-первых, в общем случае у объекта может не быть владельца.
S>>>> Например?

K_O>1. Например, у объекта, передающего аргументы от одного объекта другому
K_O> при возникновении события.
S>>Владелец меняется — сначала первый объект, потом второй.

K_O>2. Или при возникновении исключительной ситуации.
S>>Владелец — рантайм.

K_O>Кто в каждом из этих случаев должен удалять объект?

Последний в цепочке обработчиков.

K_O>В каких случаях GC неприемлем?

Распределённая система.

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

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

MN>>Теперь второе про объект нельзя говорить, что он того или иного типа. Объект может быть определённого класса и реализовывать определённые типы — чувствуете разницу?

SYG>А класс (CLASS) — это значит больше не тип, да?
Нет не тип, потому что тип — используется для разрешения классификации выражений. А класс — для описаня и создания объектов в некоторых объектно-ориентированных языках.

SYG>А интерфейс (INTERFACE) — это тип или это что такое?

Интерфейс — это контракт описывающий требования к клиенту и обязанности объекта.

SYG>Один объект реализовывает или все-таки весь класс данных объектов реализовывает какой-то интерфейс?

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

SYG>А знаете, вот например, в Оберонах вообще нет ни классов, ни интерфейсов и связанной с ними терминологической путанницы тоже нет; зато есть тип RECORD и понятие TYPE EXTENSION — расширение типа. И ничего — самые крутые языки. Есть тип запись RECORD, который может быть 1) обычным, 2) EXTENSIBLE, 3) ABSTRACT, 4) LIMITED.

А в языке Self тоже нет понятия класса, но есть понятие объекта и есть понятие интерфейса. И наследование реализовано не в виде статического копирования реализации и декларации из базового класса в дочерний, а в виде делегирования. И проблем никаких не возникает. И интерфейс реализует не класс, а именно объект. И много чего ещё...
Ну что может попросим линейку в студию, да замерим у кого длиннее, или может хватит бросаться словами "крутые языки" умеют то-то и то-то...

Hello, Kh_Oleg!
You wrote on Wed, 25 Aug 2004 10:40:36 GMT:

KO> 1. Например, у объекта, передающего аргументы от одного объекта другому
KO> при возникновении события.
S>> Владелец меняется — сначала первый объект, потом второй.

KO> 2. Или при возникновении исключительной ситуации.
S>> Владелец — рантайм.

KO> Кто в каждом из этих случаев должен удалять объект?

Можно по-разному реализовать. Например, для первого случая, передачи объекта
можно избежать вовсе, заменив ее копированием объекта параметров,
принадлежащего уисточнику события, объекту параметров приемника события.
Можно возложить ответственность на последний из обработчиков событий, можно
поручить это источнику события. В общем, вариантов масса.

S>> Речь шла о принципиальной возможности, а не о недостатках.
KO> Принципиально много что возможно, даже взлом самых стойких
KO> алгоритмов шифрования. Вопрос в стоимости.

Это для тебя вопрос в стоимости. А я с Губановым спорил о принципиальной
осуществимости.

KO>>> Касательно ваших вариантов — первый вариант чреват неочевидностью
KO>>> (точнее плохой наглядностью) в том, кто должен получать оповещения и
KO>>> в каком порядке. Нужно сверхтщательно отслеживать свой код, чтобы не
KO>>> допустить зацикливания таких оповещений.

S>> В результате чего программист наконец понимает, что же он такое написал
S>>
KO> Через два месяца отладки, безнадежно сорвав сроки релиза.

А если не поймет — то отстанет на четыре месяца

KO>>> Третий вариант мне предстваляется просто частным решением проблемы,
KO>>> которое в некоторых случаях приемлемо, а в других — нет.
S>> Сброщик мусора — такое же частное решение, которое в некоторых случаях
S>> приемлемо, а в других — нет.

KO> В каких случаях GC неприемлем?

Любые системы, от которых требуется детерминированное время отклика. Mr.
None еще распределенные системы подсказывает. Учитывая, что под сборкой
мусора мы тут понимаем не только работу с памятью, но и работу с любыми
объектами (инициатор топика, S.Yu.Gubanov, утверждал, что полноценный GC
должен оперировать также файлами и железом), область применения GC еще более
сужается.

S>> И позволяет обеспечить при этом жесткий реалтайм или детерминированное
S>> поведение исполнительных механизмов

KO> На самом деле, вопрос о необходимости такого детерминизма — это
KO> отдельная тема.

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

With best regards, Sergey.

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

SYG>Обратите внимание на то что процедуры
SYG>

SYG>PROCEDURE ObjectA.DoSmth();
SYG>PROCEDURE ObjectB.DoSmth();
SYG>

SYG>НЕ виртуальные! Это самые обычные объектные процедуры.

Чего-то у меня возникли сомнения по этому поводу Кинь плиз ссылочку на какой-нибудь онлайновый мануал по CP, где можно про это почитать.
Я сейчас целый час искал — нашел только Language Report и What's New, но там вообще про INTERFACE ни слова нету

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 10:46:06 GMT:

S>> Объект, реализующий доступ к файлу в виндах -
S>> он какого типа? А интерфейс к критической секции — это что, тип?

SG> Винды не ОО ситема так что там фиг знает какого типа.

Подсистема ввода-вывода и оконная подсистема — ОО. Хочешь поспорить?

SG> А в ОО системах тип объектов известен.

Типа у объекта вообще может не быть в том смысле, который ты в это понятие
вкладываешь.

SG> Я про файлы в ОО системах уже писал:
SG> http://www.rsdn.ru/Forum/Message.aspx?mid=725451&amp;only=1

Автор: S.Yu.Gubanov
Дата: 19.07.04

Это к делу не относится. Совершенно.

SG> Кроме того, представьте себе что файл — это персистентный объект.

Я тебе привел конкретный пример. Если тот факт, что ты лучше знаешь, как
должен быть устроен и работать файл, мешает тебя понять смысл примера, я
могу привести другой пример — окно, скажем. Окно в виндах какого типа?

With best regards, Sergey.

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

E>Я сейчас целый час искал

Так, пардон, то ведь был пример из Delphi... В CP неким приблизительным аналогом INTERFACE будет POINTER TO ABSTRACT RECORD. А в Zonnon-e вместо них появились DEFINITION.

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

S>Я тебе привел конкретный пример. Если тот факт, что ты лучше знаешь, как
S>должен быть устроен и работать файл, мешает тебя понять смысл примера, я
S>могу привести другой пример — окно, скажем. Окно в виндах какого типа?

Окно, это то которое с кнопочками? У меня и с окнами те же самые проблемы:
http://www.rsdn.ru/Forum/Message.aspx?mid=697423&amp;only=1

Автор: S.Yu.Gubanov
Дата: 28.06.04

Окно есть просто объект предоставляющий место на экране монитора, а внутри него (места) рисуется документ со всеми контролами. В ОО системах все ихние типы тоже известны. Один и тот же документ можно открыть в нескольких окнах (синхронизация по паттерну Model-View-Controller)

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

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

E>>Я сейчас целый час искал

SYG>Так, пардон, то ведь был пример из Delphi...
Ну да. Я уж и сам догадался
И как же тогда понимать эту фразу?

НЕ виртуальные! Это самые обычные объектные процедуры.

Вообще говоря, эти процедуры таки виртуальны.
То что их указатели хранятся не напрямую в VMT самого класса (хотя могут и там и там), а опосредованно, через список по смещению vmtIntfTable — не принципиально.

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

MN>Поясните пожалуйста, что значит виртуальный и что значит переопределяться...

Это довольно мутная часть стандарта. Понимать ее можно примерно так:

class C1
{
    virtual class B 
    { 
        ....
    }
    public B myAttribute;
}

class C2 : C1
{
   redefined class B
   {
   }
}

C1 v1 = new C1();
C2 v2 = new C2();
C1 v3 = new C2();

v1.myAttribute имеет тип C1::B

v2.myAttribute имеет тип C2::B

v3.myAttribute имеет тип C2::B

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 12:11:48 GMT:

SG> Окно, это то которое с кнопочками? У меня и с окнами те же самые
SG> проблемы: http://www.rsdn.ru/Forum/Message.aspx?mid=697423&amp;only=1

Автор: S.Yu.Gubanov
Дата: 28.06.04

Ну тогда давай рассмотрим объекты синхронизации Или к ним у тебе тоже
претензии есть?

SG> Окно есть просто объект предоставляющий место на экране монитора, а
SG> внутри него (места) рисуется документ со всеми контролами.

Ну и какого типа этот объект? А какого типа контролы, которые тоже окна?
Конкретнее — какого типа EDIT, а какого — SysTreeView32?

SG> В ОО системах все ихние типы тоже известны.

НЕ ОБЯЗАТЕЛЬНО!!!

SG>
Один и тот же документ
SG> можно открыть в нескольких окнах (синхронизация по паттерну
SG> Model-View-Controller)

Ну и причем здесь это???

With best regards, Sergey.

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

KO>> 1. Например, у объекта, передающего аргументы от одного объекта другому
KO>> при возникновении события.
S>>> Владелец меняется — сначала первый объект, потом второй.

KO>> 2. Или при возникновении исключительной ситуации.
S>>> Владелец — рантайм.

KO>> Кто в каждом из этих случаев должен удалять объект?

S>Можно по-разному реализовать. Например, для первого случая, передачи объекта
S>можно избежать вовсе, заменив ее копированием объекта параметров,
S>принадлежащего уисточнику события, объекту параметров приемника события.
Нельзя — теряем performance!

S>Можно возложить ответственность на последний из обработчиков событий,
Так обычно и происходит, по крайней мере с исключениеями. Только ранее было сказано,
что удалять должен владелец, немного позднее — что владельцем объекта-исключения
является runtime, а теперь — что удаляет объект не runtime, стало быть имеют место
случаи, когда объект либо не имеет владельца, либо не всегда владелец должен объект
удалять.

S>можно поручить это источнику события. В общем, вариантов масса.
Тогда прощай, асинхронные события.

S>>> Речь шла о принципиальной возможности, а не о недостатках.
KO>> Принципиально много что возможно, даже взлом самых стойких
KO>> алгоритмов шифрования. Вопрос в стоимости.

S>Это для тебя вопрос в стоимости. А я с Губановым спорил о принципиальной
S>осуществимости.

Ну, я, конечно, сознаю, что влез в ваш спор, только форум вроде как публичный...

KO>> В каких случаях GC неприемлем?

S>Любые системы, от которых требуется детерминированное время отклика. Mr.
S>None еще распределенные системы подсказывает. Учитывая, что под сборкой
S>мусора мы тут понимаем не только работу с памятью, но и работу с любыми
S>объектами (инициатор топика, S.Yu.Gubanov, утверждал, что полноценный GC
S>должен оперировать также файлами и железом), область применения GC еще более
S>сужается.

S>>> И позволяет обеспечить при этом жесткий реалтайм или детерминированное
S>>> поведение исполнительных механизмов

KO>> На самом деле, вопрос о необходимости такого детерминизма — это
KO>> отдельная тема.

S>Кстати, существет масса задач, где недопустимо даже обычное динамическое
S>распределение памяти, не то что GC

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

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

E>Вообще говоря, эти процедуры таки виртуальны.
E>То что их указатели хранятся не напрямую в VMT самого класса (хотя могут и там и там), а опосредованно, через список по смещению vmtIntfTable — не принципиально.

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

p := a;
p.DoSmth(); // через таблицу
a.DoSmth(); // непосредственно

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

MN>>Поясните пожалуйста, что значит виртуальный и что значит переопределяться...

_O_>Это довольно мутная часть стандарта. Понимать ее можно примерно так:

_O_>

_O_>class C1
_O_>{
_O_>    virtual class B 
_O_>    { 
_O_>        ....
_O_>    }
_O_>    public B myAttribute;
_O_>}

_O_>class C2 : C1
_O_>{
_O_>   redefined class B
_O_>   {
_O_>   }
_O_>}

_O_>C1 v1 = new C1();
_O_>C2 v2 = new C2();
_O_>C1 v3 = new C2();
_O_>v1.myAttribute имеет тип C1::B
_O_>v2.myAttribute имеет тип C2::B
_O_>v3.myAttribute имеет тип C2::B
_O_>

Ага примерно, то что я и ожидал увидеть. Только один маленький вопрос:
если интерфейсы у C1::B и C2::B буду совершенно различаться, как компилятор должен будет обрабатывать вызовы методов для v3.myAttribute... здаётся мне, что это применимо только для языков с динамической типизацией...

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

S>Ну тогда давай рассмотрим объекты синхронизации Или к ним у тебе тоже
S>претензии есть?

А как же, конечно есть. В Active Oberon вся многопоточность спрятана внутри активных объектов. Подробности в диссере Питера Мюллера.


S>Ну и какого типа этот объект? А какого типа контролы, которые тоже окна?
S>Конкретнее — какого типа EDIT, а какого — SysTreeView32?

Не просекаю я смысла Вашего вопроса. Мне надо назвать конкретные имена типов используемых, например, в оберонистом BlackBox-е или что?

Есть модуль Controls там описан тип

Controls = POINTER TO ABSTRACT RECORD (Views.View)
             //...
           END;

Все контролы есть его расширения.

Hello, Kh_Oleg!
You wrote on Wed, 25 Aug 2004 12:52:44 GMT:

S>> Можно по-разному реализовать. Например, для первого случая, передачи
S>> объекта можно избежать вовсе, заменив ее копированием объекта
S>> параметров, принадлежащего уисточнику события, объекту параметров
S>> приемника события.
KO> Нельзя — теряем performance!

В большинстве случаев — нет. Если копирование объекта параметров (P)
дорогое, помимо объекта P объект O -владелец объекта P, копирование которого
дешево. Объект О передается вместо параметра, в момент копирования объекта О
осуществляется передача владения. Проще говоря, тут вполне катит рефкаунт.

S>> Можно возложить ответственность на последний из обработчиков событий,
KO> Так обычно и происходит, по крайней мере с исключениеями.

Обычно в С++ объекты исключений передаются по ссылке и код управления
временем жизни объекта исключения целиком создается компилятором, т.е.
владелец — рантайм. А ты про какой язык говоришь?

KO> Только ранее было сказано, что удалять должен владелец, немного позднее
KO> — что владельцем объекта-исключения является runtime,

Иногда — рантайм, иногда — нет.

KO> а теперь — что
KO> удаляет объект не runtime,

Когда как. Если владелец — не runtime, то и удаляет не он.

KO> стало быть имеют место случаи, когда объект
KO> либо не имеет владельца, либо не всегда владелец должен объект удалять.

Это не следует из того, что было сказано выше.

S>> можно поручить это источнику события. В общем, вариантов масса.

S>> KO> Тогда прощай, асинхронные события.

Разумеется, если нужны асинхронные события, удалением объекта параметров не
должен заниматься источник события. Тут идеально подходит рефкаунт.

KO> Ну, я, конечно, сознаю, что влез в ваш спор, только форум вроде как
KO> публичный...

Хочешь обсудить недостатки и преимущества GC — обсуждай их с кем нибудь
другим, мне это не интересно. Желательно в новой теме

S>> Кстати, существет масса задач, где недопустимо даже обычное
S>> динамическое распределение памяти, не то что GC

KO> Похоже, здесь затронуты вопросы на более общем уровне.

Угу, на самом общем.

KO> Я рассуждал с точки зрения построения реальных систем.

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

With best regards, Sergey.

Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 13:09:43 GMT:

S>> Ну и какого типа этот объект? А какого типа контролы, которые тоже
S>> окна? Конкретнее — какого типа EDIT, а какого — SysTreeView32?

SG> Не просекаю я смысла Вашего вопроса.

Смысл очень простой. Ты утверждаешь, что любой объект должен иметь тип. Я
утверждаю, что в ОС MS Windows есть несколько классов окон — EDIT,
SysTreeView32, SysListView32, SysTabControl32 и прошу тебя назвать их тип.
Вопрос задан с целью показать тебе, что термин "тип" ты употребляешь
некорректно. Попутно я готов доказать, что подсистема окон в MS Windows
удовлетворяет критериям ООП, а именно объекты-окна обладают полиморфизмом,
инкапсуляцией и могут наследоваться.

SG> Мне надо назвать конкретные имена типов используемых, например, в
SG> оберонистом BlackBox-е или что?

Нет, в Windows.

With best regards, Sergey.

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


MN>Ага примерно, то что я и ожидал увидеть. Только один маленький вопрос:
MN>если интерфейсы у C1::B и C2::B буду совершенно различаться, как компилятор должен будет обрабатывать вызовы методов для v3.myAttribute... здаётся мне, что это применимо только для языков с динамической типизацией...

Это UML, для него пока нет полноценной run-time семантики. В зависимости от языка кодогенерации будут применяться разные подходы. В случае ЯП с динамической типизацией все, конечно, проще. Но можно и в С генерить, если генеренный код никто не будет смотреть и менять


P.S.
Можно задавать constraint-ы на виртуальные типы. Тогда все redefined типы должны будут удовлетворять тем же constraint-ам. Это несколько облегчает кодогенерацию.

P.P.S
Imho, такуя экзотику надо повыкидывать из UML-я. Там помимо этого, есть еще куча странностей, наподобие виртуальных атрибутов, виртуальных параметров операций, виртуальных шаблонных параметров, наследования одного шаблонного параметра от другого и т.д.

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

S>Смысл очень простой. Ты утверждаешь, что любой объект должен иметь тип. Я
S>утверждаю, что в ОС MS Windows есть несколько классов окон — EDIT,
S>SysTreeView32, SysListView32, SysTabControl32 и прошу тебя назвать их тип.
S>Вопрос задан с целью показать тебе, что термин "тип" ты употребляешь
S>некорректно. Попутно я готов доказать, что подсистема окон в MS Windows
S>удовлетворяет критериям ООП, а именно объекты-окна обладают полиморфизмом,
S>инкапсуляцией и могут наследоваться.

Я не знаю. Если можешь, то расскажи. Мне интересно.

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

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


MN>>Ага примерно, то что я и ожидал увидеть. Только один маленький вопрос:
MN>>если интерфейсы у C1::B и C2::B буду совершенно различаться, как компилятор должен будет обрабатывать вызовы методов для v3.myAttribute... здаётся мне, что это применимо только для языков с динамической типизацией...

_O_>Это UML, для него пока нет полноценной run-time семантики. В зависимости от языка кодогенерации будут применяться разные подходы. В случае ЯП с динамической типизацией все, конечно, проще. Но можно и в С генерить, если генеренный код никто не будет смотреть и менять

Мне надо было поразмыслить чуть-чуть, чтобы найти ответ. И вот он. Данная возможность никак не противоречит концепциям ООП. И уж точно не является "полиморфным" типом. Название виртуальный — это так, для красивого словца. Полиморфный — значит многообразный, то есть предоставляющий множество вариаций. А теперь внимание, сами типы C1::B и C2::B остаются неизменными и жёстко фиксированными, они не полиморфны, а как раз мономорфны (термин придуман мной в противовес полиморфному, поэтому если кому не нравится не пинайте ). А изменению подвержены правили разрешения типов. Налицо динамическое переопределение типов, доступное в любом языке с динамической типизацией (я не большой знакто Smalltalk`а, но уверен, что что-нибудь подобное там возможно). Нечто похожее, но более ограниченное по возможностям, доступно даже в плюсах на шаблонах.

_O_>P.P.S
_O_>Imho, такуя экзотику надо повыкидывать из UML-я. Там помимо этого, есть еще куча странностей, наподобие виртуальных атрибутов, виртуальных параметров операций, виртуальных шаблонных параметров, наследования одного шаблонного параметра от другого и т.д.

Согласен, IMHO — бред какой-то. Хотя может это способ навести хоть некоторый порядок в проектировании для языков с динамической типизацией. Там и не такое возможно . Напрмер, в Smalltalke возможна попытка вызова для объекта несуществующего метода — всегда заканчивается исключением периода исполнения, но сам факт возможности этого остаётся.

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

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

S>>Смысл очень простой. Ты утверждаешь, что любой объект должен иметь тип. Я
S>>утверждаю, что в ОС MS Windows есть несколько классов окон — EDIT,
S>>SysTreeView32, SysListView32, SysTabControl32 и прошу тебя назвать их тип.
S>>Вопрос задан с целью показать тебе, что термин "тип" ты употребляешь
S>>некорректно. Попутно я готов доказать, что подсистема окон в MS Windows
S>>удовлетворяет критериям ООП, а именно объекты-окна обладают полиморфизмом,
S>>инкапсуляцией и могут наследоваться.

SYG>Я не знаю. Если можешь, то расскажи. Мне интересно.

Я надеюсь Sergey не обидется, если я сделаю это за него. Вот только критерии объектной ориентированности у меня несколько отличаются. Точнее не уменя, а у Энтони Элиентса — его критерии классификации описаны в более широком смысле и нравятся мне больше, чем все остальные. Итак:
1) наличие понятия объект — в оконной подсистеме Windows присуствует понятие объект пользовательского интерфейса, мы не знаем что это такое, для нас это некий чёрный ящик, предоставляемый системой;
2) наличие средства разделения ресурсов между объектом родителем и его потомком (наследование в том понимании, в котором оно принято в C++, есть частный случай данного критерия, основаный на статическом копировании кода родителя в код потомка при компиляции) — субклассинг объектов пользовательского интерфейса;
3) инкапсуляция или скрывание внутренностей реализации объекта за фиксированным интерфейсом — функции WinAPI по работе с объектами пользовательского интерфейса;
4) понятие типа, как средства классификации выражений — все объекты пользовательского интерфейса доступны нам через переменные типа HANDLE.

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

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

MN>Согласен, IMHO — бред какой-то. Хотя может это способ навести хоть некоторый порядок в проектировании для языков с динамической типизацией. Там и не такое возможно . Напрмер, в Smalltalke возможна попытка вызова для объекта несуществующего метода — всегда заканчивается исключением периода исполнения, но сам факт возможности этого остаётся.


Не, это способ навести беспорядок. Просто стандарт делает куча компаний и каждая из них приходит со своим бэкграундом и наработками. А академическое сообщество еще большие кракозябры родить может (см http://www.cs.york.ac.uk/puml, http://2uworks.org)
В результате UML2.0 не может быть реализуем в полном объеме и с приемлимой эффективностью ни на каком популярном языке программирования.

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

MN>4) понятие типа, как средства классификации выражений — все объекты пользовательского интерфейса доступны нам через переменные типа HANDLE.
MN>Итак подсистема пользовательского интерфейса — это ОО система.

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

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

Hello, S.Yu.Gubanov!
You wrote on Fri, 27 Aug 2004 07:04:48 GMT:

MN>> 4) понятие типа, как средства классификации выражений — все объекты
MN>> пользовательского интерфейса доступны нам через переменные типа
MN>> HANDLE. Итак подсистема пользовательского интерфейса — это ОО система.

SG> Если вся речь шла о тех штуках, которые в Винодсе доступны через
SG> HANDLE,

В основном о тех, что доступны через HWND — это у Mr. None просто опечатка.
Впрочем, объектов, доступных через HANDLE это тоже касается.

SG> то это вовсе не объектно ориентированная система, а объектно
SG> основанная система.

Здрасте. А кто запрещает написать свой контрол? И регистрировать его оконный
класс при загрузке соответствующей Dll? Причем результат будет неотличим от
использования контролов из comctl32.dll.
Точно так же можно написать драйвер устройства, с которым пользовательская
программа будет общаться через CreateFile/ReadFile и т.д.

With best regards, Sergey.

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

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

MN>>4) понятие типа, как средства классификации выражений — все объекты пользовательского интерфейса доступны нам через переменные типа HANDLE.
MN>>Итак подсистема пользовательского интерфейса — это ОО система.

SYG>Если вся речь шла о тех штуках, которые в Винодсе доступны через HANDLE, то это вовсе не объектно ориентированная система, а объектно основанная система.

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

К сожалению я не знаю, что такое объектно основанная система, в общех чертах представляю только что такое объектная система, она включает в себя следующие основные элементы: объект, инкапсуляция, абстрактный тип данных, имеющий большее влияние на объект, нежели в ООП (наследования нет, но создавать свои объекты можно). Поэтому, если это не то же самое, будьте добры дать ссылку на определение из общедоступного доверительного источника.
Это было первое, теперь второе. В подсистеме пользовательского интерфейса Windows вы можете собственноручно создавать новые элементы пользовательского интерфейса и наследоваться от уже существующих.
И если честно, то мне не совсем понятно, как упоминание о типе переменной для доступа (как верно пометил Sergey — я ошибся не HANDLE, а HWND) связано с заключением о том, что система не является объектно-ориентированной. Если оно основано лишь на том, что вы не можете пораждать свои типы для доступа к объектам, то этот вывод ошибочный. Вам о том и твердят, что понятие типа может никак не влиять на объекты в частности и объектную-ориентацию системы вообще. Вот конкретный пример, вы не можете задавать свой тип для доступа к объектам пользовательского интерфейса или наследоваться от уже существующего, но вы запросто можете создавать свои объекты и иерархии.

Hello, Mr.!
You wrote on Fri, 27 Aug 2004 08:16:07 GMT:

MN> К сожалению я не знаю, что такое объектно основанная система, в

Ну vbscript и javascript часто называют object-based, потому что там нельзя
свои объекты создавать. Соответственно, применительно к оконной системе
Губанов не прав.

With best regards, Sergey.

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

MN>И если честно, то мне не совсем понятно, как упоминание о типе переменной для доступа (как верно пометил Sergey — я ошибся не HANDLE, а HWND) связано с заключением о том, что система не является объектно-ориентированной. Если оно основано лишь на том, что вы не можете пораждать свои типы для доступа к объектам, то этот вывод ошибочный. Вам о том и твердят, что понятие типа может никак не влиять на объекты в частности и объектную-ориентацию системы вообще. Вот конкретный пример, вы не можете задавать свой тип для доступа к объектам пользовательского интерфейса или наследоваться от уже существующего, но вы запросто можете создавать свои объекты и иерархии.


А, я понял в чем тут дело. Когда я пытался дать определения понятиям "Модульная система" и "Компонентная система", то для модульной системы я сказал, что все модули с точки зрения среды исполнения эквивалентны, но при определении компонентной системы как объектно ориентированной модульной системы, я забыл лишний раз упомянуть, что все все перевсе объекты такой системы живут в одной единственной объектной среде (точно так же как все все перевсе модули живут в одной единственной (модульной) среде). Мне просто это казалось очевидным — все объекты (и объекты создаваемые операционкой, и объекты создаваемые пользователем) с точки зрения объектной среды исполнения эквивалентны. Собственно, отсюда и проистекает возможность существования одного единственного на всю среду исполнения сборщика мусора. В том случае, о котором говорите Вы, когда доступ к объектам осуществляется с помощью РУЧЕК (handle — ручка), ни о какой единой объектной среде исполнения речи не идет — каждый "сорт ручек" представляет собой "черный ящик" — со своей собственной внутренней (никому внешнему не известной) средой исполнения.

Итак,

Модульная система = совокупность равноценных модулей работающих в одной среде исполнения.
Компонентная система = это модульная система + единая объектная среда в которой живут все-все-все объекты всей системы, и все объекты между собой тоже равноценны.

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

S>Hello, Mr.!
S>You wrote on Fri, 27 Aug 2004 08:16:07 GMT:

MN>> К сожалению я не знаю, что такое объектно основанная система, в

S>Ну vbscript и javascript часто называют object-based, потому что там нельзя
S>свои объекты создавать.

Санькс — буду знать

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

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

SYG> каждый "сорт ручек" представляет собой "черный ящик" — со своей собственной внутренней (никому внешнему не известной) средой исполнения.

Это не противоречит принципам ООП.

SYG>Модульная система = совокупность равноценных модулей работающих в одной среде исполнения.
SYG>Компонентная система = это модульная система + единая объектная среда в которой живут все-все-все объекты всей системы, и все объекты между собой тоже равноценны.

А как же быть с распределёнными приложениями? По вашему определению выходит, что любая распределённая система не может является компонентной. Потому что любой удалённый объект живёт в некой внешней и никому неизвестной среде исполнения, и доступ к нему возможен только через прокси, который является неким аналогом описателя (handle &mdash; описатель, дескриптор).

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

MN>А как же быть с распределёнными приложениями? По вашему определению выходит, что любая распределённая система не может является компонентной.

А что такое вообще операционная система работающая не на одном компьютере, а на десяти?
Один компьютер — одна операционка. По моему всегда отношение 1:1.

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

S>>Ну vbscript и javascript часто называют object-based, потому что там нельзя
S>>свои объекты создавать.

MN>Санькс — буду знать

Еще есть такой язык — SALUTE, он внутри корпоративной информационной системы "Флагман" от Инфософта работает.

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

MN>>А как же быть с распределёнными приложениями? По вашему определению выходит, что любая распределённая система не может является компонентной.

SYG>А что такое вообще операционная система работающая не на одном компьютере, а на десяти?
SYG>Один компьютер — одна операционка. По моему всегда отношение 1:1.
Кто сказал операционныя система? Было сказано распереленное приложение те приложение части которого выполняются на разных компах.

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

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

MN>>А как же быть с распределёнными приложениями? По вашему определению выходит, что любая распределённая система не может является компонентной.

SYG>А что такое вообще операционная система работающая не на одном компьютере, а на десяти?
SYG>Один компьютер — одна операционка. По моему всегда отношение 1:1.

Во-первых, речь кажется идёт о концепции компонентных системах вообще, а не об операционных системах в частности.
Во-вторых, пожалуйста примеры, где выполняется соотношение n:1 — много компьютеров одна операционка:
некоторые грид-системы при некоторых условиях можно назвать операционками;
системы, обеспечивающие функциональность кластеров — тоже самое.

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

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

S>>>Ну vbscript и javascript часто называют object-based, потому что там нельзя
S>>>свои объекты создавать.

MN>>Санькс — буду знать

SYG>Еще есть такой язык — SALUTE, он внутри корпоративной информационной системы "Флагман" от Инфософта работает.

Это вы упомянули потому, что "НИКА-КОМ первой в регионе получила статус Сертифицированного дилера компании Инфософт"?

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

MN>Это вы упомянули потому, что "НИКА-КОМ первой в регионе получила статус Сертифицированного дилера компании Инфософт"?

Угадали. Я в НИКА-КОМ полтора года работал, за то время и на SALUT-е успел отчеты построгать.
Кстати, похвастаюсь, http://www.ncom.ru/win/soft/marsh_master.htm — полностью я сделал.

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

MN>>>А как же быть с распределёнными приложениями? По вашему определению выходит, что любая распределённая система не может является компонентной.


MN>некоторые грид-системы при некоторых условиях можно назвать операционками;
MN>системы, обеспечивающие функциональность кластеров — тоже самое.


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