Здравствуйте, Kluev, Вы писали:
K>Более того драйвер и не должен принимать решение. С какой это стати? Если вызывающий код запрашивает ресурс то он же его и освобождает.
Ну тогда нечего приводить драйверы Windows как пример компонентной среды. В данном случае они выступают просто в роли внешних пассивных библиотек.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Kluev, Вы писали:
K>>Более того драйвер и не должен принимать решение. С какой это стати? Если вызывающий код запрашивает ресурс то он же его и освобождает.
SYG>Ну тогда нечего приводить драйверы Windows как пример компонентной среды. В данном случае они выступают просто в роли внешних пассивных библиотек.
Здравствуйте, Kluev, Вы писали:
K>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.
Типичные но не все. Кроме того слово "компонент" очень широко в своем смысле. Да, конечно, в каком-то смысле этого слова данная система "компонентна". Но драйверы Windows не компонентны в смысле Компонентно ориентированного программирования (КОП).
Определение КОП (данное Клеменсом Шиперски еще 10 лет назад) таково:
КОП = ООП
+ модульность (включая упрятывание информации и позднее связывание модулей, т.е. возможность подгружать необходимые модули в процессе выполнения программы, а не заранее, как это обычно делается в старых системах программирования)
+ безопасность (статический контроль типов переменных и автоматическое управление памятью)
— наследование через границы модулей.
Последняя строчка означает, что в КОП запрещено наследование от типов, реализованных в других модулях; наследовать можно только абстрактным, чисто интерфейсным типам.
Компонентно-ориентированное программирование возникло как своего рода дисциплина, т.е. набор определенных ограничений, налагаемых на механизм ООП, когда стало ясно, что бесконтрольное использование ООП приводит к проблемам с надежностью больших программных комплексов.
Hello, S.Yu.Gubanov!
You wrote on Thu, 19 Aug 2004 10:53:43 GMT:
SG> системах программирования) + безопасность (статический контроль типов SG> переменных и автоматическое управление памятью) — наследование через SG> границы модулей.
SG> Последняя строчка означает, что в КОП запрещено наследование от типов, SG> реализованных в других модулях; наследовать можно только абстрактным, SG> чисто интерфейсным типам.
Что-то фигня у вас какая-то получается. Наследование к типам, вообще-то, не
привязано. Делаю я, скажем, subclassing TreeView — это в чистом виде
наследование моего триконтрола от виндового. При этом какого он там типа в
comctl32.dll и класс ли это вообще (в С++ терминах), меня совершенно не
интересует. А интерфейс у него вообще сишный, а не плюсовый, так что
разговор об абстрактных, чисто интерфейсных типах переходит в несколько
другую плоскость.
С драйверами примерно такая же фигня.
Disclaimer: Я не утверждаю, что модель драйверов или окон в Windows является
или не является компонентной. Я утверждаю только, что аргументация у вас
хромает.
SG> Компонентно-ориентированное программирование возникло как своего рода SG> дисциплина, т.е. набор определенных ограничений, налагаемых на механизм SG> ООП, когда стало ясно, что бесконтрольное использование ООП приводит к SG> проблемам с надежностью больших программных комплексов.
Лучший компонент — компилябельный исходник с документацией
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Hello, S.Yu.Gubanov! S>You wrote on Thu, 19 Aug 2004 10:53:43 GMT:
S>Что-то фигня у вас какая-то получается. Наследование к типам, вообще-то, не S>привязано. Делаю я, скажем, subclassing TreeView — это в чистом виде S>наследование моего триконтрола от виндового. При этом какого он там типа в S>comctl32.dll и класс ли это вообще (в С++ терминах), меня совершенно не S>интересует.
Есть подозрение, что вы путаете наследование типов и наследование объектов.
Subclassing — классическое наследование объекта. И к типам не имеет отношения.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Hello, xvost!
You wrote on Thu, 19 Aug 2004 11:42:40 GMT:
S>> Что-то фигня у вас какая-то получается. Наследование к типам, S>> вообще-то, не привязано. Делаю я, скажем, subclassing TreeView — это в S>> чистом виде наследование моего триконтрола от виндового. При этом S>> какого он там типа в comctl32.dll и класс ли это вообще (в С++ S>> терминах), меня совершенно не интересует.
x> Есть подозрение, что вы путаете наследование типов и наследование x> объектов.
Есть подозрение, что это S.Yu.Gubanov путает
x> Subclassing — классическое наследование объекта. И к типам не имеет x> отношения.
Вот и я о том же. Наследование типов к виндовым драйверам и оконной системе
отношения не имеет. Как, впрочем, и к ООП. Оно, собственно говоря, вообще
является фичей конкретного языка.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Kluev, Вы писали:
K>>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.
SYG>Типичные но не все. Кроме того слово "компонент" очень широко в своем смысле. Да, конечно, в каком-то смысле этого слова данная система "компонентна". Но драйверы Windows не компонентны в смысле Компонентно ориентированного программирования (КОП).
Компонентны-по полной программе. Драйвер можно запустить без перезагрузки системы, а другая компонентность здесь не требуется. Все остальные требования тоже соблюдены кроме автоматического контроля памяти.
Здравствуйте, Kluev, Вы писали:
K>Компонентны-по полной программе. Драйвер можно запустить без перезагрузки системы, а другая компонентность здесь не требуется. Все остальные требования тоже соблюдены кроме автоматического контроля памяти.
+1 Кроме того, зачем нам автоматический контроль, если в данном контексте он нам не нужен? От этого система более убогой не становится. А если драйвер совсем кривой то думаю поведение BSOD система всегда сможет правильно воспроизвезти, в его отношении Так что на заданном уровне, я согласен, система является компонентной.
Здравствуйте, S.Yu.Gubanov, Вы писали:
K>>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.
[...цитата поскипана...]
ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...
Да, действительно, с тех пор как было придумано КОП (более 10 лет назад) термин "компонент" чуть ли не каждый стал трактовать по своему не утруждая себя придумать другой термин. Вот и бардакс..
Здравствуйте, Sergey, Вы писали:
S>Наследование к типам, вообще-то, не привязано.
Там имелось в виду, что в одном модуле пишется интерфейс, а в другом модуле целиком пишется реализация. Реализация не экспортируется — она скрыта от внешнего мира. Модуль экспортирует только полиморфные переменные (с заданным в том первом модуле интерфейсом). Таким образом, модули общаются между собой передавая друг другу не сами объекты, а полиморфные переменные связанные с этими объектами. Слово "наследование" было употреблено в том смысле, что во многих языках программирования реализация интерфейса сводится к наследованию от абстрактного класса, а класс — это просто один из типов.
Hello, S.Yu.Gubanov!
You wrote on Mon, 23 Aug 2004 06:46:44 GMT:
SG> Там имелось в виду, что в одном модуле пишется интерфейс, а в другом SG> модуле целиком пишется реализация.
Какая разница? Интерфейс вообще может быть реализован в трех-четырех модулях
для разных языков.
SG> Реализация не экспортируется — она скрыта от внешнего мира. Модуль SG> экспортирует только полиморфные переменные (с заданным в том первом SG> модуле интерфейсом).
Допустим, написал я свой драйвер файловой системы — реализация никуда не
экспортируется, интерфейс к новой файловой системе предоставляется все теми
же CreateFile/WriteFile/ReadFile. Чем не компонента?
SG> Таким образом, модули общаются между собой передавая друг другу не сами SG> объекты, а полиморфные переменные связанные с этими объектами.
Этому условию замечательно соответсвуют оконная подсистема виндов, API
работы с файлами и куча всего еще. В роли "полиморфной переменной" в этом
случае выступают HWND и HANDLE.
SG> Слово SG> "наследование" было употреблено в том смысле, что во многих языках SG> программирования реализация интерфейса сводится к наследованию от SG> абстрактного класса, а класс — это просто один из типов.
Ну раз уж ты заговорил о парадигмах программирования, то неплохо было бы
обходится без привязки к конкретным языкам.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Чем не компонента?
Компонент чего?
Может ли обычное виндозное пользовательское приложение напрямую запускать Вашу программу или же все-таки Ваша программа должна работать в режиме ядра виндос?
Вот в оберонах драйверы — это, действительно, компоненты так как там нет разницы между модулями операционки и обычными пользовательскими модулями — все они совершенно эквивалентны.
Вот как устроена обычная допотопная операционка типа виндос или юникс:
Module_i — это модули операционки + модули системных сервисов + модули пользователей; между всеми ними нет никакой принципиальной разницы — вот Вам пожалуйста компонентная система.
Hello, S.Yu.Gubanov!
You wrote on Mon, 23 Aug 2004 14:41:55 GMT:
S>> Чем не компонента?
SG> Компонент чего?
Операционной системы, естественно.
SG> Может ли обычное виндозное пользовательское приложение напрямую SG> запускать Вашу программу или же все-таки Ваша программа должна работать SG> в режиме ядра виндос?
Противопоставление тут неуместно. Во-первых, не все драйвера работают в
режиме ядра, во-вторых, бывают загружаемые по требованию драйвера, в
третьих, я говорил не только не только про драйвера, но и про оконную
подсистему. И наконец — причем тут kernel mode? Ну работает драйвер в режиме
ядра, и какому критерию КОП это мешает?
SG> Module_i — это модули операционки + модули системных сервисов + модули SG> пользователей; между всеми ними нет никакой принципиальной разницы - SG> вот Вам пожалуйста компонентная система.
Ну и в чем принципальная разница между comctl32.dll и mycoolcontrol.dll? Или
хотя бы в чем принципиальная разница между драйвером и пользовательским
модулем?
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Hello, S.Yu.Gubanov! S>You wrote on Mon, 23 Aug 2004 14:41:55 GMT:
S>>> Чем не компонента?
SG>> Компонент чего?
S>Операционной системы, естественно.
Ничего подобного. Объяснения довольно большие и я решил изложить их в отдельной ветке этого форума:
