Здравствуйте, artelk, Вы писали: A>Например, добавить в Crash "private readonly Guid id = Guid.NewGuid();", реализовать Equals через него. A>В чем подвох? Решение перестанет быть ООП?
Нет. В таком варианте — не перестанет
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали: S>>А ты нажми на ссылку "Transaction Script", которую он приводит. ANS>Нажал. Всё равно пока не понимаю.
Я что, забыл написать "прочитай то, что написано по ссылке"?
Прошу прощения.
A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into subprocedures.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>>>С чего ты взял? COM — бинарный стандарт, он не знает про интерфейсы в .NET и наследование в C++, да и вообще про типы. Но по счастливой случайности бинарный формат на выходе компилятора MSVC++ совпадает с COM. S>>>>Не понял, причем тут интерфейсы в дотнет и наследование в C++. Речь об расширении контрактов в COM. На чем хочешь пиши, хоть на асме. G>>>Так ты сам начал такой разговор. В COM приведение типов выполняется с помощью QueryInterface, то что ты можешь в C++ получить IUnknown* из вообще любого участка памяти никакого отношения к COM не имеет. S>>Я не говорил о получении IUnknown из вообще любого участка памяти. Я чисто об multiple interface navigation, который невозможен без использования состояния. G>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта.
Обращение к QI может вернуть другой указатель, чем указатель, по которому к нему обратились. Так как любой интерфейс COM (даже еще не объявленный) расширяет IUnknown, то любой указатель, вернувшийся из QI является указателем на IUnknown. G>Это не получится также, как иметь разные ссылки на один объект в CLR. Ты по второму кругу попадаешь в одну и ту же ошибку.
Интерфейс IUnknown будет в объекте COM единственным с точностью до указателя. А указателей на интерфейсы может быть очень дофига. При этом каждый из них будет указывать на реализацию IUnknown.
Тут мы походу запутались. Рассмотрим выражение "указатель на IUnknown". Его можно понимать как тип указателя (IUnknown*), который может указывать на все что угодно, что имеет совместимость с IUnknown. и я его понимаю именно так. Кстати, я добавлял IUnknown* на всякий случай. А можно понимать как "указатель на COM интерфейс IUnknown" в смысле (p->QueryInterface(IID_IUnknown, &pUnknown)).
Так вот, по спеке два указателя на IUnknown интерфейс одного и того же объекта должны быть равны. Но два (IUnknown*) указателя на разные интерфейсы одного объекта равны быть не должны.
Напиши все-таки код QI, разрешающий навигацию между интерфейсами и не использующий состояние. Или все-таки признай, что COM identity test использует состояние.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>>>>>С чего ты взял? COM — бинарный стандарт, он не знает про интерфейсы в .NET и наследование в C++, да и вообще про типы. Но по счастливой случайности бинарный формат на выходе компилятора MSVC++ совпадает с COM. S>>>>>Не понял, причем тут интерфейсы в дотнет и наследование в C++. Речь об расширении контрактов в COM. На чем хочешь пиши, хоть на асме. G>>>>Так ты сам начал такой разговор. В COM приведение типов выполняется с помощью QueryInterface, то что ты можешь в C++ получить IUnknown* из вообще любого участка памяти никакого отношения к COM не имеет. S>>>Я не говорил о получении IUnknown из вообще любого участка памяти. Я чисто об multiple interface navigation, который невозможен без использования состояния. G>>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. S>Обращение к QI может вернуть другой указатель, чем указатель, по которому к нему обратились. Так как любой интерфейс COM (даже еще не объявленный) расширяет IUnknown, то любой указатель, вернувшийся из QI является указателем на IUnknown.
Что значит "является указателем IUnknown" ? Тут ты говоришь в терминах ООП в С++. С точки зрения COM единственный способ получения IUnknown — выполнить QUeryInterface. Я и говорю. что ты рассматриваешь какую-то смесь COM и C++, которая COM не является.
S>Напиши все-таки код QI, разрешающий навигацию между интерфейсами и не использующий состояние. Или все-таки признай, что COM identity test использует состояние.
Ты же сам писал что если наблюдаемое поведение не зависит от состояния, то значит совсем не зависит. В случае COM это выполняется. Если нужна реализация, то пусть возвращается всегда первый face.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. S>>Обращение к QI может вернуть другой указатель, чем указатель, по которому к нему обратились. Так как любой интерфейс COM (даже еще не объявленный) расширяет IUnknown, то любой указатель, вернувшийся из QI является указателем на IUnknown. G>Что значит "является указателем IUnknown" ? Тут ты говоришь в терминах ООП в С++. С точки зрения COM единственный способ получения IUnknown — выполнить QUeryInterface. Я и говорю. что ты рассматриваешь какую-то смесь COM и C++, которая COM не является.
All interfaces in COM are polymorphic with IUnknown, that is, if you look at the first three functions in any interface you see QueryInterface, AddRef, and Release. In other words, IUnknown is base interface from which
all other interfaces inherit.
Посему указатель на любой интерфейс любого COM объекта есть указатель на IUnknown.
S>>Напиши все-таки код QI, разрешающий навигацию между интерфейсами и не использующий состояние. Или все-таки признай, что COM identity test использует состояние. G>Ты же сам писал что если наблюдаемое поведение не зависит от состояния, то значит совсем не зависит.
Ты же был там со мной категорически несогласен. А тут ссылаешься на меня?
G>В случае COM это выполняется.
Нет. Нигде не написано что QI не может изменять состояние объекта. Более того, оно именно это и делает, согласно многим сценариям COM. QI не является детерминированной в общем случае. Потому тут нельзя так легко отречься от использования состояния.
G>Если нужна реализация, то пусть возвращается всегда первый face.
Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>>>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. S>>>Обращение к QI может вернуть другой указатель, чем указатель, по которому к нему обратились. Так как любой интерфейс COM (даже еще не объявленный) расширяет IUnknown, то любой указатель, вернувшийся из QI является указателем на IUnknown. G>>Что значит "является указателем IUnknown" ? Тут ты говоришь в терминах ООП в С++. С точки зрения COM единственный способ получения IUnknown — выполнить QUeryInterface. Я и говорю. что ты рассматриваешь какую-то смесь COM и C++, которая COM не является. S>
S>All interfaces in COM are polymorphic with IUnknown, that is, if you look at the first three functions in any interface you see QueryInterface, AddRef, and Release. In other words, IUnknown is base interface from which
S>all other interfaces inherit.
S>Посему указатель на любой интерфейс любого COM объекта есть указатель на IUnknown.
И? Приведение типа в смысле C++ не является корректной операцией в COM. Для этого надо делать QueryInterface.
S>>>Напиши все-таки код QI, разрешающий навигацию между интерфейсами и не использующий состояние. Или все-таки признай, что COM identity test использует состояние. G>>Ты же сам писал что если наблюдаемое поведение не зависит от состояния, то значит совсем не зависит. S>Ты же был там со мной категорически несогласен. А тут ссылаешься на меня?
Нет, я лишь сказал что вычисления можно заменить константой если они вычисляют одно и то же значение.
G>>В случае COM это выполняется. S>Нет. Нигде не написано что QI не может изменять состояние объекта. Более того, оно именно это и делает, согласно многим сценариям COM.
Покажи пример чтоли.
S>QI не является детерминированной в общем случае.
Для IUnknown — является. Этого достаточно.
G>>Если нужна реализация, то пусть возвращается всегда первый face. S>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью.
Первый по порядку (любому).
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>>>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. S>>>>Обращение к QI может вернуть другой указатель, чем указатель, по которому к нему обратились. Так как любой интерфейс COM (даже еще не объявленный) расширяет IUnknown, то любой указатель, вернувшийся из QI является указателем на IUnknown. G>>>Что значит "является указателем IUnknown" ? Тут ты говоришь в терминах ООП в С++. С точки зрения COM единственный способ получения IUnknown — выполнить QUeryInterface. Я и говорю. что ты рассматриваешь какую-то смесь COM и C++, которая COM не является. S>>
S>>All interfaces in COM are polymorphic with IUnknown, that is, if you look at the first three functions in any interface you see QueryInterface, AddRef, and Release. In other words, IUnknown is base interface from which
S>>all other interfaces inherit.
S>>Посему указатель на любой интерфейс любого COM объекта есть указатель на IUnknown. G>И? Приведение типа в смысле C++ не является корректной операцией в COM. Для этого надо делать QueryInterface.
Предлагаю отказаться от бесполезной полемики о легальности кода
Бесполезная она потому как не приведет ни к чему.
Предлагаю рассмотреть следующий пример:
IXXX *pXXX;
IYYY *pYYY;
pUnk->QueryInterface(IID_IXXX, &pXXX);
pUnk->QueryInterface(IID_IYYY, &pYYY);
// HRESULT-ы корректные, в pXXX и pYYY не NULL-ы, pXXX != pYYY
Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели.
Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат?
S>>>>Напиши все-таки код QI, разрешающий навигацию между интерфейсами и не использующий состояние. Или все-таки признай, что COM identity test использует состояние. G>>>Ты же сам писал что если наблюдаемое поведение не зависит от состояния, то значит совсем не зависит. S>>Ты же был там со мной категорически несогласен. А тут ссылаешься на меня? G>Нет, я лишь сказал что вычисления можно заменить константой если они вычисляют одно и то же значение.
Ой, что я проглядел-то (смотрю на выделенное)!
Давай разберемся. QI — это такая функция, которая формально множество идентификаторов отображает на множество указателей
QI: GUID -> void*
Так вот, QI(IID_IUnknown) должна возвращать указатель на IUnknown грань. В нетривиальных случаях, когда объект имеет multiple interface, результат QI(IID_IUnknown) должен где-то хранитсья. Подозреваю что в состоянии, а никак не в константе. И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал?
G>>>В случае COM это выполняется. S>>Нет. Нигде не написано что QI не может изменять состояние объекта. Более того, оно именно это и делает, согласно многим сценариям COM. G>Покажи пример чтоли.
Вот пример такого сценария из спеки (3.3.1.1)
In contrast, queries for interfaces other than IUnknown are not required to return the same
actual pointer value each time a QueryInterface returning one of them is called. This, among
other things, enables sophisticated object implementors to free individual interfaces on
their objects when they are not being used, recreating them on demand (reference
counting is a per-interface notion, as is explained further below).
S>>QI не является детерминированной в общем случае. G>Для IUnknown — является. Этого достаточно.
Этого недостаточно что бы считать QI независящей от состояния даже в случае IUnknown.
G>>>Если нужна реализация, то пусть возвращается всегда первый face. S>>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью. G>Первый по порядку (любому).
Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты?
Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, artelk, Вы писали: A>>Я утверждаю, что именно идентичность, реализованная в языке, позволяет нам иметь гарантии, что в последних 3х строчках мы имеем дело с одним и тем же объектом. S>А я утверждаю, что по определению идентичность в ООП требует возможности различать объекты независимо от их состояния и поведения.
Да, мы можем различать объекты независимо от их состояния и поведения, например:
class A { public int X; }
var a1 = new A();
var a2 = new A();
a1.X = 1;
Debug.Assert(a1.X == 1);
a2.X = 1;
Debug.Assert(a2.X == 1);
a2.X = 2;
Debug.Assert(a2.X == 2);
Debug.Assert(a1.X == 1);//все ещеvar b1 = a1;
b1.X = 3;
Debug.Assert(b1.X == 3);
Debug.Assert(a1.X == 3);//поскольку a1 ≡ b1
Debug.Assert(a2.X == 2);//все еще
Все assert-ы верны. Ссылки a1 и a2 ссылаются на различные объекты. Ссылки a1 и b1 — на идентичные.
И это должно гарантироваться языком. И это называется identity.
Здравствуйте, artelk, Вы писали:
A>Все assert-ы верны. Ссылки a1 и a2 ссылаются на различные объекты. Ссылки a1 и b1 — на идентичные.
Я не вижу здесь различения объектов независимо от их состояния и поведения.
Все проверки делаются на основе исключительно поведения объектов.
Предположение об идентичности объектов проверяется путём сравнения переходов состояний.
В то же время, как мы тут выяснили среди сотен сообщений в этом топике, из синхронности поведения объектов нельзя делать вывод об их идентичности.
Наоборот — можно.
A>И это должно гарантироваться языком. И это называется identity.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>Если рассматривать ООП с точки зрения Кея, то и erlang с процессами более чем соответствует. ANS>Это упрощение. Ты из акцента на messaging (подразумевается наличие чего-то еще), оставил *только* messaging. А ведь была еще и концепция "только объект", которая подразумевает "рекурсивный дизайн", когда объекты состоят из объектов на макро и микро уровне. В Erlang процессы (как единица хранения состояния) и сообщения есть только на макро уровне.
Так Эрланг и есть ОО с т.з. Кея именно на таком уровне. Точно так же если спуститься на уровень битов, то любой язык резко перестанет быть ОО
Здравствуйте, samius, Вы писали:
S>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели. S>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат?
Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение.
Можно добавить еще одну "грань" к которой приводить. И снова любое честное и неочень изменение состояния не нарушит поведение, специфицированное COM.
S>Так вот, QI(IID_IUnknown) должна возвращать указатель на IUnknown грань. В нетривиальных случаях, когда объект имеет multiple interface, результат QI(IID_IUnknown) должен где-то хранитсья.
Это будет еще одна грань напрмиер.
S>Подозреваю что в состоянии, а никак не в константе.
Ниугадал.
S>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал?
Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет.
Вообще странно что ты не можешь придумать как сделать множественное наследование интерфейсов, которое работает только через this. Эта задача уже многократно реализована.
S>>>QI не является детерминированной в общем случае. G>>Для IUnknown — является. Этого достаточно. S>Этого недостаточно что бы считать QI независящей от состояния даже в случае IUnknown.
А что тогда считать "независимостью от состояния"? Тогда любой из твоих ранее приведенных примеров идентичности зависит от состояния.
Независимость от состояния обозначает ровно одно — результат функции не меняется при любом (честно или нет) изменении состояния объекта.
В COM всегда можно сделать реализацию identity, которая при любом изменении состояния, не нарушающим целостность объекта, не будет зависеть от состояния.
G>>>>Если нужна реализация, то пусть возвращается всегда первый face. S>>>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью. G>>Первый по порядку (любому). S>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты?
Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, artelk, Вы писали: A>>Например, добавить в Crash "private readonly Guid id = Guid.NewGuid();", реализовать Equals через него. A>>В чем подвох? Решение перестанет быть ООП? S>Нет. В таком варианте — не перестанет
Т.е. object.ReferenceEquals не является обязательным. Если нам требуется уникальность объектов в коллекции, мы можем добиться этого имеющимися средствами, так?
Здравствуйте, gandjustas, Вы писали: G>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. Что, нетривиальная штука — COM?
Это всё сделано на случай агрегации. G>Это не получится также, как иметь разные ссылки на один объект в CLR. Ты по второму кругу попадаешь в одну и ту же ошибку.
Увы — получится. Надо просто отличать два понятия:
1. Просто указатель на IUnknown — любой указатель в COM является также и указателем на IUnknown. По причине наследования интерфейсов.
2. Указатель на IUnknown, полученный в ответ на QI(IID_IUnknown).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>Тогда приведи корректный с точки зрения COM способ получения разных указателей на IUnknown для одного объекта. S> Что, нетривиальная штука — COM? S>Это всё сделано на случай агрегации. G>>Это не получится также, как иметь разные ссылки на один объект в CLR. Ты по второму кругу попадаешь в одну и ту же ошибку. S>Увы — получится. Надо просто отличать два понятия: S>1. Просто указатель на IUnknown — любой указатель в COM является также и указателем на IUnknown. По причине наследования интерфейсов. S>2. Указатель на IUnknown, полученный в ответ на QI(IID_IUnknown).
Да, но "приведение типов" с точки зрения com не совсем законная операция. Чтобы получить указатель на конкретный интерфейс надо обяpательно выполнять QI.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели. S>>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат? G>Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение.
Где предлагаешь хранить коллекцию интерфейсов, если не в состоянии?
G>Можно добавить еще одну "грань" к которой приводить. И снова любое честное и неочень изменение состояния не нарушит поведение, специфицированное COM.
Где хранить указатель на грань?
S>>Так вот, QI(IID_IUnknown) должна возвращать указатель на IUnknown грань. В нетривиальных случаях, когда объект имеет multiple interface, результат QI(IID_IUnknown) должен где-то хранитсья. G>Это будет еще одна грань напрмиер.
Так где будем хранить указатель?
S>>Подозреваю что в состоянии, а никак не в константе. G>Ниугадал.
покажи код
S>>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал? G>Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет.
Реализация наследования в каком-то языке не покрывает сценарии использования СOM. В дотнет тем более.
G>Вообще странно что ты не можешь придумать как сделать множественное наследование интерфейсов, которое работает только через this. Эта задача уже многократно реализована.
Демагогия детектед.
Не по адресу — спеку COM писал не я.
Не вовремя — спеку писали очень давно и уже успели налабать толпу кода, так что предложение запоздало.
Не в кассу — разработчики COM знали про множественное наследование, просто они COM разрабатывали не под языки со множественным наследованием и предполагали сценарии реюза объектов отличные от множественного наследования и composition/delegation, в том числе cross-language сценарии реюза и расширения.
S>>>>QI не является детерминированной в общем случае. G>>>Для IUnknown — является. Этого достаточно. S>>Этого недостаточно что бы считать QI независящей от состояния даже в случае IUnknown. G>А что тогда считать "независимостью от состояния"? Тогда любой из твоих ранее приведенных примеров идентичности зависит от состояния. G>Независимость от состояния обозначает ровно одно — результат функции не меняется при любом (честно или нет) изменении состояния объекта.
Об этом не очень спортивно говорить, когда ты берешь состояние и возвращаешь его в качестве результата.
G>В COM всегда можно сделать реализацию identity, которая при любом изменении состояния, не нарушающим целостность объекта, не будет зависеть от состояния.
Что бы оперировать такими аргументами, ты должен согласиться с ними сперва. Ты же мне говорил что "опираться на состояние" не по правилам вычисления identity.
G>>>>>Если нужна реализация, то пусть возвращается всегда первый face. S>>>>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью. G>>>Первый по порядку (любому). S>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты? G>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface.
Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы.
И вообще, QI придумали именно для того, что бы обрулить сценарии расширения и реюза. Он такой именно поэтому. И идентичность в COM определена через QI именно для этих целей. В своем маленьком объекте, не предназначенном для расширения, ты можешь так и сделать. Но мы говорим об идентичности в COM, а не идентичности COM объекта написанного на C++ и не предполагающего расширение.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели. S>>>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат? G>>Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение. S>Где предлагаешь хранить коллекцию интерфейсов, если не в состоянии?
Его не надо хранить. Ты заранее выбери один интерфейс, к которому будет приводиться.
G>>Можно добавить еще одну "грань" к которой приводить. И снова любое честное и неочень изменение состояния не нарушит поведение, специфицированное COM. S>Где хранить указатель на грань?
Его не надо хранить, его надо возвращать. Можно прямо в том case, который ты ранее рисовал.
S>>>Подозреваю что в состоянии, а никак не в константе. G>>Ниугадал. S>покажи код
return (IUnknown*)this;
S>>>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал? G>>Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет. S>Реализация наследования в каком-то языке не покрывает сценарии использования СOM. В дотнет тем более.
Не все сценарии, но основные вполне, для которых COM создавался — вполне. Некоторые фичи com по-моему вообще в дикой природе не встретишь.
G>>>>>>Если нужна реализация, то пусть возвращается всегда первый face. S>>>>>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью. G>>>>Первый по порядку (любому). S>>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты? G>>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface. S>Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы.
Я предлагаю решение для сценария, который ты сам придумал. Ведь можно и другой сценарий придумать, который будет не менее рабочий, и не менее COM.
S>И вообще, QI придумали именно для того, что бы обрулить сценарии расширения и реюза. Он такой именно поэтому. И идентичность в COM определена через QI именно для этих целей. В своем маленьком объекте, не предназначенном для расширения, ты можешь так и сделать. Но мы говорим об идентичности в COM, а не идентичности COM объекта написанного на C++ и не предполагающего расширение.
Без разницы, главное чтобы QueryInterface(IUnknown) возвращал всегда одно значение, независимо от состояния и поведения.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>>>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели. S>>>>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат? G>>>Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение. S>>Где предлагаешь хранить коллекцию интерфейсов, если не в состоянии? G>Его не надо хранить. Ты заранее выбери один интерфейс, к которому будет приводиться.
Интерфейсы pXXX и pYYY лежат в разных местах. Нужна навигация между ними. Приведением навигацию не обеспечить.
G>>>Можно добавить еще одну "грань" к которой приводить. И снова любое честное и неочень изменение состояния не нарушит поведение, специфицированное COM. S>>Где хранить указатель на грань? G>Его не надо хранить, его надо возвращать. Можно прямо в том case, который ты ранее рисовал.
S>>>>Подозреваю что в состоянии, а никак не в константе. G>>>Ниугадал. S>>покажи код
G>
G>return (IUnknown*)this;
G>
this указывает на грань, отличную от IID_IUnknown. Как быть?
S>>>>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал? G>>>Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет. S>>Реализация наследования в каком-то языке не покрывает сценарии использования СOM. В дотнет тем более. G>Не все сценарии, но основные вполне, для которых COM создавался — вполне. Некоторые фичи com по-моему вообще в дикой природе не встретишь.
Так ты предлагаешь отказаться от сценариев, где требуется состояние для реализации QI для того что бы убедить меня в том, что разработчики спеки не подразумевали использование состояния в QI при вычислении identity?
G>>>>>Первый по порядку (любому). S>>>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты? G>>>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface. S>>Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы. G>Я предлагаю решение для сценария, который ты сам придумал. Ведь можно и другой сценарий придумать, который будет не менее рабочий, и не менее COM.
Сценарий multiple interface navigation придумал не я. Это довольно типичный сценарий в COM уровня чуть глубже букварного. В спеке он упоминается неоднократно, даже с примерами реализации.
S>>И вообще, QI придумали именно для того, что бы обрулить сценарии расширения и реюза. Он такой именно поэтому. И идентичность в COM определена через QI именно для этих целей. В своем маленьком объекте, не предназначенном для расширения, ты можешь так и сделать. Но мы говорим об идентичности в COM, а не идентичности COM объекта написанного на C++ и не предполагающего расширение. G>Без разницы, главное чтобы QueryInterface(IUnknown) возвращал всегда одно значение, независимо от состояния и поведения.
Не без разницы. Я тебе указываю на те случаи, когда результат QI нужно хранить в состоянии грани. Ты их упорно игнорируешь.
Я все жду, какой сценарий ты предпочтешь...
а) COM использует состояние в вычислении ID, значит незазорно использовать данные строки при сравнении двух строк.
б) COM не использует состояние в вычислении ID, значит сравнение строк не использует состояние.
Здравствуйте, artelk, Вы писали: A>Т.е. object.ReferenceEquals не является обязательным. Если нам требуется уникальность объектов в коллекции, мы можем добиться этого имеющимися средствами, так?
В том случае, если у нас есть альтернативный механизм identity — да.
Вы только что его ввели. Если identity нет, то мы огребаем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Да, но "приведение типов" с точки зрения com не совсем законная операция. Чтобы получить указатель на конкретный интерфейс надо обяpательно выполнять QI.
Вот в этом я не уверен. Беглый просмотр интернетов не дал ответа на вопрос, обязан ли я перезапрашивать интерфейс-предок, или таки нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>>>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели. S>>>>>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат? G>>>>Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение. S>>>Где предлагаешь хранить коллекцию интерфейсов, если не в состоянии? G>>Его не надо хранить. Ты заранее выбери один интерфейс, к которому будет приводиться. S>Интерфейсы pXXX и pYYY лежат в разных местах. Нужна навигация между ними. Приведением навигацию не обеспечить.
Да без разницы, нам только надо возвращать всегда одинаковую ссылку на QueryInterface(IUnknown), остальное не интересует.
G>>
G>>return (IUnknown*)this;
G>>
S>this указывает на грань, отличную от IID_IUnknown. Как быть?
Пусть указывает, ведь каждый интерфейс является всегда IUnknown и при данной реализации всегда будет возвращать одно значение.
Или ты что-то другое имеешь ввиду?
S>>>>>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал? G>>>>Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет. S>>>Реализация наследования в каком-то языке не покрывает сценарии использования СOM. В дотнет тем более. G>>Не все сценарии, но основные вполне, для которых COM создавался — вполне. Некоторые фичи com по-моему вообще в дикой природе не встретишь. S>Так ты предлагаешь отказаться от сценариев, где требуется состояние для реализации QI для того что бы убедить меня в том, что разработчики спеки не подразумевали использование состояния в QI при вычислении identity?
Нет, я лишь говорю что если ты придумываешь сложности — ты их и решай. Но принципиальных проблем обеспечить независимость от состояния QueryInterface(IUnknown) я не вижу.
G>>>>>>Первый по порядку (любому). S>>>>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты? G>>>>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface. S>>>Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы. G>>Я предлагаю решение для сценария, который ты сам придумал. Ведь можно и другой сценарий придумать, который будет не менее рабочий, и не менее COM. S>Сценарий multiple interface navigation придумал не я. Это довольно типичный сценарий в COM уровня чуть глубже букварного. В спеке он упоминается неоднократно, даже с примерами реализации.
А пример такого в компонентах есть?
S>>>И вообще, QI придумали именно для того, что бы обрулить сценарии расширения и реюза. Он такой именно поэтому. И идентичность в COM определена через QI именно для этих целей. В своем маленьком объекте, не предназначенном для расширения, ты можешь так и сделать. Но мы говорим об идентичности в COM, а не идентичности COM объекта написанного на C++ и не предполагающего расширение. G>>Без разницы, главное чтобы QueryInterface(IUnknown) возвращал всегда одно значение, независимо от состояния и поведения. S>Не без разницы. Я тебе указываю на те случаи, когда результат QI нужно хранить в состоянии грани. Ты их упорно игнорируешь.
Если ты сделал такую реализацию что надо хранить, то ССЗБ. Не делай такую реализацию. Я же тебе говорил что можно почти все сделать через механизмы множественного наследования, которые уже давно работают в разных языках.
Что, нетривиальная штука — COM? 