Здравствуйте, 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 — описатель, дескриптор).

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

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

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

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

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

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

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