Здравствуйте, 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 тип может быть виртуальным и переопределяться в наследниках контейнера, содержащего данный тип.