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.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, Sergey, Вы писали:
SG>> Во-первых, в общем случае у объекта может не быть владельца. S>Например?
Например, у объекта, передающего аргументы от одного объекта другому
при возникновении события. Или при возникновении исключительной ситуации.
SG>> А во-вторых, я уже предлагал Вам решить задачку когда владелец объекта SG>> сообщил внешнему миру о своем подопечном объекте и теперь не может его SG>> из-за этого уничтожить опасаясь что внешний мир им все еще пользуется.
S>И что? Один из вариантов решения такой — протокол передачи объекта внешнему S>миру должен предусматривать способ оповестить внешний мир о том, что объект S>вскоре будет уничтожен, дождаться подтверждения готовности внешнего мира к S>этому событию и уничтожить объект. Другой вариант — банальный рефкаунт. S>Третий — диспетчер объектов какого-то конкретного класса, через который и S>осуществляется доступ к объектам.
Это все хорошо в теории и для относительно небольших программ. В очень больших
сложных системах, с высокой степенью связности между подсистемами, правильное
уничтожение объектов, причем в правильной последовательности, является огромной
проблемой и источником трудноотлаживаемых ошибок. Я не спорю, что связность — это
плохо, но не всегда удается "развязать" систему.
Касательно ваших вариантов — первый вариант чреват неочевидностью (точнее плохой
наглядностью) в том, кто должен получать оповещения и в каком порядке. Нужно
сверхтщательно отслеживать свой код, чтобы не допустить зацикливания таких оповещений.
При reference counting'е тоже не все гладко. Как правило, после введения такой фишки
в свой проект, приходится писать что-то вроде AutoPtr, чтобы не загромождать код
бесконечными AddRef и Release. Ньюансов, которые при этом могут возникнуть — сотни,
не все их сначала учтешь, а потом, когда программа начинает валиться с ошибкой доступа,
нужно очень много времени, что размотать эту цепочку присваиваний-переприсваиваний-копирований-удалений
с отслеживанием состояния счетчика привязок и обнаружить, что вот при такой особенной ситуации
происходит неправильное обновление счетчика привязок.
Третий вариант мне предстваляется просто частным решением проблемы, которое в некоторых
случаях приемлемо, а в других — нет.
Тогда как сборщик мусора — это системное решение проблемы уничтожения объектов, которое
перекладывает большой кусок работы с плеч программиста на плечи операционной системы
(ну или среды исполнения), позволяя первому сосредоточиться на решении прикладных задач,
связанных с проблемной областью.
Re[12]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, Mr. None, Вы писали:
MN>Теперь второе про объект нельзя говорить, что он того или иного типа. Объект может быть определённого класса и реализовывать определённые типы — чувствуете разницу?
А класс (CLASS) — это значит больше не тип, да? А интерфейс (INTERFACE) — это тип или это что такое? Один объект реализовывает или все-таки весь класс данных объектов реализовывает какой-то интерфейс? Не забивайте себе голову. А знаете, вот например, в Оберонах вообще нет ни классов, ни интерфейсов и связанной с ними терминологической путанницы тоже нет; зато есть тип RECORD и понятие TYPE EXTENSION — расширение типа. И ничего — самые крутые языки. Есть тип запись RECORD, который может быть 1) обычным, 2) EXTENSIBLE, 3) ABSTRACT, 4) LIMITED. Если он EXTENSIBLE или ABSTRACT то его можно расширять (ну то есть как бы наследоваться). Если он ABSTRACT, то его переменных создать нельзя, а надо сначала определить новый тип — его расширение (потомок) и если он будет объявлен как не ABSTRACT, то переменные создавать можно будет. Если LIMITED — то переменные можно создавать только внутри модуля в котором этот тип определен.
Re[13]: Что такое "модульные" или "компонентные" системы?
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.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[13]: Что такое "модульные" или "компонентные" системы?
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.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[9]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, _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
Re[14]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, 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>поведение исполнительных механизмов
На самом деле, вопрос о необходимости такого детерминизма — это отдельная тема.
Re[14]: Что такое "модульные" или "компонентные" системы?
Кроме того, представьте себе что файл — это персистентный объект. Тогда файловая система Вам больше не нужна, а нужна "всего лишь" Объектная СУБД. Когда-нибудь какую-нибудь объектную СУБД интегрирует внутрь какой-нибудь системы исполнения, вот будет крутизна...
Re[10]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Здравствуйте, Mr. None, Вы писали:
SYG>Ах да, совсем забыл!!! А вот, например, в Delphi есть метаклассы — это типы переменные которых принимают значения самих классов объектов. Вот уж точно полиморфный-переполиморфный тип.
Нет — это концепция метаклассов. Она прекрасно ложится в объектно-ориентированную парадигму и более того при правильной реализации помагает раскрыть сущность самого понятия класс. Класс — это такой же объект, только умеющий пораждать другие объекты. Вот только во многих упрощённых реализациях класс практически отождествляется с понятием типа и существует только на этапе компиляции, что не есть верно.
А полиморфный тип — это судя по всему нечто такое, что умеет менять свою структуру неким произвольным образом... То есть сегодня MyCleverInterface содержит функции fun1 и fun2, а завтра уже some_fun1, some_fun2 и some_fun3... Может и возможно такое, но только в какой-нибудь нечёткой логике, но никак ни в программировании, покрайней мере не в ООП.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[9]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, Mr. None, Вы писали:
MN>>Речь идён конкретно об Объектно Ориентированной Парадигме. В её рамках такого понятия как полиморфный тип не сущетсвует.
_O_>В UML 2.0 тип может быть виртуальным и переопределяться в наследниках контейнера, содержащего данный тип.
Поясните пожалуйста, что значит виртуальный и что значит переопределяться...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[15]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Здравствуйте, Sergey, Вы писали:
SG>>>>> Во-первых, в общем случае у объекта может не быть владельца. S>>>> Например?
K_O>1. Например, у объекта, передающего аргументы от одного объекта другому K_O> при возникновении события. S>>Владелец меняется — сначала первый объект, потом второй.
K_O>2. Или при возникновении исключительной ситуации. S>>Владелец — рантайм.
K_O>Кто в каждом из этих случаев должен удалять объект?
Последний в цепочке обработчиков.
K_O>В каких случаях GC неприемлем?
Распределённая система.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[13]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, 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 тоже нет понятия класса, но есть понятие объекта и есть понятие интерфейса. И наследование реализовано не в виде статического копирования реализации и декларации из базового класса в дочерний, а в виде делегирования. И проблем никаких не возникает. И интерфейс реализует не класс, а именно объект. И много чего ещё...
Ну что может попросим линейку в студию, да замерим у кого длиннее, или может хватит бросаться словами "крутые языки" умеют то-то и то-то...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[15]: Что такое "модульные" или "компонентные" системы?
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.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[9]: Что такое "модульные" или "компонентные" системы?
SYG>НЕ виртуальные! Это самые обычные объектные процедуры.
Чего-то у меня возникли сомнения по этому поводу Кинь плиз ссылочку на какой-нибудь онлайновый мануал по CP, где можно про это почитать.
Я сейчас целый час искал — нашел только Language Report и What's New, но там вообще про INTERFACE ни слова нету
... << RSDN@Home 1.1.3 stable >>
Re[15]: Что такое "модульные" или "компонентные" системы?
Hello, S.Yu.Gubanov!
You wrote on Wed, 25 Aug 2004 10:46:06 GMT:
S>> Объект, реализующий доступ к файлу в виндах - S>> он какого типа? А интерфейс к критической секции — это что, тип?
SG> Винды не ОО ситема так что там фиг знает какого типа.
Подсистема ввода-вывода и оконная подсистема — ОО. Хочешь поспорить?
SG> А в ОО системах тип объектов известен.
Это к делу не относится. Совершенно.
SG> Кроме того, представьте себе что файл — это персистентный объект.
Я тебе привел конкретный пример. Если тот факт, что ты лучше знаешь, как
должен быть устроен и работать файл, мешает тебя понять смысл примера, я
могу привести другой пример — окно, скажем. Окно в виндах какого типа?
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[10]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, eugals, Вы писали:
E>Я сейчас целый час искал
Так, пардон, то ведь был пример из Delphi... В CP неким приблизительным аналогом INTERFACE будет POINTER TO ABSTRACT RECORD. А в Zonnon-e вместо них появились DEFINITION.
Re[16]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, Sergey, Вы писали:
S>Я тебе привел конкретный пример. Если тот факт, что ты лучше знаешь, как S>должен быть устроен и работать файл, мешает тебя понять смысл примера, я S>могу привести другой пример — окно, скажем. Окно в виндах какого типа?
Окно есть просто объект предоставляющий место на экране монитора, а внутри него (места) рисуется документ со всеми контролами. В ОО системах все ихние типы тоже известны. Один и тот же документ можно открыть в нескольких окнах (синхронизация по паттерну Model-View-Controller)
Re[11]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, eugals, Вы писали:
E>>Я сейчас целый час искал
SYG>Так, пардон, то ведь был пример из Delphi...
Ну да. Я уж и сам догадался
И как же тогда понимать эту фразу?
НЕ виртуальные! Это самые обычные объектные процедуры.
Вообще говоря, эти процедуры таки виртуальны.
То что их указатели хранятся не напрямую в VMT самого класса (хотя могут и там и там), а опосредованно, через список по смещению vmtIntfTable — не принципиально.
... << RSDN@Home 1.1.3 stable >>
Re[10]: Что такое "модульные" или "компонентные" системы?
Здравствуйте, 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
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[17]: Что такое "модульные" или "компонентные" системы?
Ну тогда давай рассмотрим объекты синхронизации Или к ним у тебе тоже
претензии есть?
SG> Окно есть просто объект предоставляющий место на экране монитора, а SG> внутри него (места) рисуется документ со всеми контролами.
Ну и какого типа этот объект? А какого типа контролы, которые тоже окна?
Конкретнее — какого типа EDIT, а какого — SysTreeView32?
SG> В ОО системах все ихние типы тоже известны.
НЕ ОБЯЗАТЕЛЬНО!!!
SG>
Один и тот же документ SG> можно открыть в нескольких окнах (синхронизация по паттерну SG> Model-View-Controller)
Ну и причем здесь это???
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Один объект реализовывает или все-таки весь класс данных объектов реализовывает какой-то интерфейс? Не забивайте себе голову. 
А знаете, вот например, в Оберонах вообще нет ни классов, ни интерфейсов и связанной с ними терминологической путанницы тоже нет; зато есть тип RECORD и понятие TYPE EXTENSION — расширение типа. И ничего — самые крутые языки. Есть тип запись RECORD, который может быть 1) обычным, 2) EXTENSIBLE, 3) ABSTRACT, 4) LIMITED. Если он EXTENSIBLE или ABSTRACT то его можно расширять (ну то есть как бы наследоваться). Если он ABSTRACT, то его переменных создать нельзя, а надо сначала определить новый тип — его расширение (потомок) и если он будет объявлен как не ABSTRACT, то переменные создавать можно будет. Если LIMITED — то переменные можно создавать только внутри модуля в котором этот тип определен.
Кинь плиз ссылочку на какой-нибудь онлайновый мануал по CP, где можно про это почитать.
В CP неким приблизительным аналогом INTERFACE будет POINTER TO ABSTRACT RECORD. А в Zonnon-e вместо них появились DEFINITION.
