Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Хм, именно так, через структурную эквивалентность в ECMA определили identity для value type И сказали считать их идентичными. Т.е. два разных значения, в разных location, они велели считать идентичными. Ничего не смущает? Я о том и говорю, что именно идентичность говорит что считать идентичным чему. G>Не смущает. Value-type находится за пределами ООП, там это совершенно нормально.
Окей, пусть Value не ООП. А COM разве не уточняет понятие идентичности? G>Мы ведь все еще про ООП говорим, не так ли?
Да.
S>>Я не представляю, о какой специфике ты говоришь. На бумаге тоже пока никто не записал иррационального числа. До сих пор только обозначали их. G>Нет, на бумаге мы оперируем символьными вычислениями, а в компьютере — значениями.
И компьютер и бумага позволяют нам использовать абстракции. В частности, создавая в ООП класс "Дробь" мы можем пользоваться не значениями а символьными вычислениями.
G>>>>>Тогда их сравнивать бессмысленно и можно просто запретить операцию. S>>>>Зачем запрещать? Идентичность по ECMA останется. Вдруг, запретив ReferenceEquals, мы не сможем поднять рантайм? G>>>Ты же предлагаешь написать что-то, что сможет заменить referenceequals. S>>Нет, не предлагал его заменять. G>Идентичность для reference-типов в CLR реализуется referenceequals, ты хотел свою идентичность написать, то есть по сути заменить этот referenceequals.
Нет, не заменить. Я хотел показать что есть другое отношение идентичности, не совпадающее со сравнением ссылок.
S>>>>Если бы ты согласился с тем что алтернативная идентичность задает альтернативное отношение идентичности/эквивалентности объектов, то уже сам бы написал. G>>>Нету альтернативной идентичности, идентичность задается определением. Могут быть разные реализации. Но ты пока не привел ни одной, которая никак не противоречит определению. S>>Синклер приводил. G>Ага, она очень легко сводится в сравнению ссылок.
Да, наверное.
G>>>Посмотри как оно работает в COM. Там ссылки на объект могут не совпадать если запрашивать разные интерфейсы, но если запрашивать IUnknown то полученные ссылки будут совпадать. S>>Ну и незачем на него смотреть. COM явно выпадает из определения идентичности в OOP если не запрашивать IUnknown, хотя бы потому как нарушена рефлексивность. Если запрашивать IUnknown и только лишь его, то COM становится ничем не интереснее обычного объекта при условии корректной реализации. G>Ни разу не выпадает. У объектов есть identity, им можно отправлять сообщения. Там и наследование и полиморфизм тоже есть. G>То есть формально com соответствует ООП.
Формально COM соответствует OOP но лишь со своим требованием к реализации объектов, которое требует same physical pointer value у реализаций IUnknown. COM identity ослабляет identity, основанное на memory location. Если это требование не выполнить, то получится каша а не OOP.
S>>>>Давай тогда разберемся. чем идентичность отличается от отношения эквивалентности кроме требований возможности отправки сообщения по ссылке, сохранения идентичности при смене состояния? G>>>Идентичность такое отношение эквивалентности, при котором объект эквивалентен сам себе и не эквивалентен, независимо от состояния и поведения. S>>полагаю, что "не" лишняя. G>Нет, не написал что не эквивалентен другим объектам.
Если не эквивалентен другим, тогда понятно. Но это неверно. Идентичность определяет где один объект, а где другой. Не хочешь смотреть на CLR value type — посмотри на COM, где для идентичности сделана оговорка про IUnknown.
S>>Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность. G>Но value-types — не ооп. Там свойство идентичности, которое говорит о том что для идентичных объектов любое изменение в одном отражается на другом, не выполняется.
А если запретить изменения в value типе? Не во всех, а в конкретном? Он станет OOP?
S>>>>Что может мою идентичность сделать неидентичностью в общем смысле? Что ее отличает от идентичности ECMA — я догадываюсь G>>>То что твоя идентичность будет зависеть от состояния и\или поведения. S>>Не будет. G>Ты же сам говоришь что она будет реализована через операцию сравнения полей (состояния).
Я уже писал что независимость идентичности от состояния означает неизменность идентичности при изменении состояния. Нигде в определениях не запрещено сравнивать состояния.
Вот тебе задачка про COM, который ООП. Есть у тебя два сырых различных указателя IUnknown*, определи, указывают ли они на один COM объект, не используя состояние и поведение Что бы не было недопонимания, эти указатели могут указывать не на IUnknown грань, а на IDispatch, например.
G>>>>>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи. S>>>>По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что. G>>>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
S>>А я тебе говорю, что S>>1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение. G>Бинарное отношение в каком множестве? Видимо "ссылок".
8.2.5 Identity and equality of values
There are two binary operators defined on all pairs of values: identity and equality.
S>>2) существование отображения — это слишком сильное требование. Допустим, по моей identity две равных (ordered) строки будут идентичны, в отличии от ECMA-335. Ты мне создаешь функцию, которая будет всегда возвращать интернированную строку, и получается что ReferenceEquals(f(a), f(b)) == true. Хотя по определению ECMA эти строки будут разными объектами, т.к. ReferenceEquals(a, b) == false. И что ты мне хочешь доказать существованием такого отображения? Что две identity эквивалентны? Нет, они не эквивалентны. G>Нет ты опять пытаешься опираться на поведение, определяя идентичность через некоторые свойства объекта. Для начала построй идентичность, которая будет для любого типа работать, а потом будем искать f. Если ты найдешь f для какого типа идентичность не появится
Ты приводишь в пример COM, а он нарушает твою же трактовку независимости от состояния.
Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится?
S>>Забудь про отображение f. Ничего оно никому не дает. G>В COM дает, ты споришь с фактами.
В COM используется состояние для сравнения ссылок. Ты тоже споришь с фактами.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>>>Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item) S>>>>По назначенному компареру G>>>Еще раз: нет возможности переопределить операцию сравнения никак, ни компарер, ни equals, вообще никак. S>>Остается задвинуть на эту досадную коллекцию. Никто не обещал совместимость альтернативной идентичности со всем написанным кодом. G>Тем не менее коллекция есть, объект есть, сделай так чтобы Collectio.Remove(item) работало. Ведь в CLR оно работает. G>Будем считать что у тебя есть возможность сделать свою идентичность для CLR, как ты её определишь? Естественно ты тип item заранее не знаешь.
У меня не было намерений подменять идентичность в CLR. Но так и быть, если ты настаиваешь
Речи не было о том что бы взять совершенно другую идентичность. Я хотел взять немного другую идентичность, которая для некоторых хороших типов, была бы слабже чем штатная. Для всех остальных — ReferenceEquals. Соответственно, для любого наперед неизвестного типа это было бы сравнение ссылок. Для хороших типов типа строк — сравнение значений.
Собственно вот я все и выложил. Осталось ввернуть пару строк псевдокода:
bool MyIdentityEquals(object a, object b)
{
if (ReferenceEquals(a,b))
return true; // ослабить а не изменить в корнеif (a == null || b == null)
return false; // не знаю что определено в штатном порядке, пусть будет так.var type = a.GetType();
if (type != b.GetType())
return false;
if (type == typeof(string) && StringComparer.Ordinal.Equals((string)a, (string)b))
return true;
// тут обработка хороших типов.if (IsImmutable(type) && IsStructuralEquals(a, b))
return true;
return false;
}
Если это подсунуть вместо штатной ReferenceEquals и забыть про Reflection, который не ООП, то мы останемся в рамках ООП и даже возможно обеспечим некоторую совместимость с ReferenceEquals.
Да, будет тормозно. Но меня волнует лишь совместимость с ООП. Я уже говорил, что не собираюсь предлагать внедрять это в производство.
G>>>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок? S>>Я не собирался определять идентичность в CLR. Я собирался показать отношение, удовлетворяющее идентичности ООП и отличное от идентичности ECMA-335. Из CLR ты можешь на него смотреть как на еще одно отношение эквивалентности. G>Оно должно быть отношением идентичности в CLR или другой системе, которую ты придумаешь. При этом не должно существовать функции f, позволяющей свести твое отношение идентичности к сравнению "ссылок". G>Такой пример уже есть. COM — формально ООП, для идентичных объектов могут ссылки не совпадать, но при QureyInterface(IUnknown) совпадают.
Только не говори, что QueryInterface не использует состояние
S>>Но вот, незадача, еще один фронт открылся — рефлексионный... G>Никаких фронтов. Сравнение неизменяемого состояния опирается как на само состояние (значения), так и на поведение (неизменяемость). Такая эквивалентность вдвойне неправильна а CLR позволяет быстро это доказать.
COM
Здравствуйте, samius, Вы писали:
S>>>Я не представляю, о какой специфике ты говоришь. На бумаге тоже пока никто не записал иррационального числа. До сих пор только обозначали их. G>>Нет, на бумаге мы оперируем символьными вычислениями, а в компьютере — значениями. S>И компьютер и бумага позволяют нам использовать абстракции. В частности, создавая в ООП класс "Дробь" мы можем пользоваться не значениями а символьными вычислениями.
Да, и в таком случае определить функцию дирихле будет тривиально, так как само число при этом будет знать рациональное оно или нет.
G>>Идентичность для reference-типов в CLR реализуется referenceequals, ты хотел свою идентичность написать, то есть по сути заменить этот referenceequals. S>Нет, не заменить. Я хотел показать что есть другое отношение идентичности, не совпадающее со сравнением ссылок.
Это значит что его повсеместно можно использовать вместо referenceequals без изменения результатов работы программы.
S>Формально COM соответствует OOP но лишь со своим требованием к реализации объектов, которое требует same physical pointer value у реализаций IUnknown. COM identity ослабляет identity, основанное на memory location. Если это требование не выполнить, то получится каша а не OOP.
Если это требование не выполнить, то получится не COM. То есть COM — ООП.
S>Если не эквивалентен другим, тогда понятно. Но это неверно. Идентичность определяет где один объект, а где другой.
Математически это выглядит как id(a)=id(b), когда a и b — один и тот же объект, id(a)!=id(b), когда a и b — разные объекты. Я уже это формально доказывал. Соответственно нам заранее необходимо знание о разных объектах, иначе любое отношение эквивалентности можно назвать идентичностью.
Тут нам на помощь приходят свойства
1)Независимость состояния и поведения
2)если объекты идентичны, то любое изменение в одном отражается на другом.
S>хочешь смотреть на CLR value type — посмотри на COM, где для идентичности сделана оговорка про IUnknown.
Value type в CLR — не ООП, в COM идентичность определена через QueryInterface(IUnknown). Фактически любая ссылка сводится к "инвариантной", которые уже можно сравнивать для идентичности. Это та функция f, про которую я говорил.
Соответственно тебе нет смысла доказывать что существует система с какой-то идентичностью если в ней есть такая функция, которая сведет все к сравнению ссылок, так как можно тогда любые ссылки в системе заменить на "инвариантные".
S>>>Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность. G>>Но value-types — не ооп. Там свойство идентичности, которое говорит о том что для идентичных объектов любое изменение в одном отражается на другом, не выполняется. S>А если запретить изменения в value типе? Не во всех, а в конкретном? Он станет OOP?
Нет, идентичность не может быть определена "для конкретного типа", потому что "конкретный тип" это поведение от которого идентичность не должна зависеть.
S>Вот тебе задачка про COM, который ООП. Есть у тебя два сырых различных указателя IUnknown*, определи, указывают ли они на один COM объект, не используя состояние и поведение Что бы не было недопонимания, эти указатели могут указывать не на IUnknown грань, а на IDispatch, например.
QueryInterface(IUnknown) даст равные ссылки, независимо от типа\объекта и его состояния, это требование спецификации COM. Если объект не следует спецификации, то это не COM и соответственно — не ООП.
G>>>>>>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи. S>>>>>По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что. G>>>>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
S>>>А я тебе говорю, что S>>>1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение. G>>Бинарное отношение в каком множестве? Видимо "ссылок". S>
S>8.2.5 Identity and equality of values
S>There are two binary operators defined on all pairs of values: identity and equality.
Мы только про reference-типы говорим, потому что value-типы — не ООП.
G>>Нет ты опять пытаешься опираться на поведение, определяя идентичность через некоторые свойства объекта. Для начала построй идентичность, которая будет для любого типа работать, а потом будем искать f. Если ты найдешь f для какого типа идентичность не появится S>Ты приводишь в пример COM, а он нарушает твою же трактовку независимости от состояния.
Нет. Потому что любой объект при QueryInterface(IUnknown) сколько угодно раз должен возвращать одно то же значение, независимо от типа и состояния.
Это и есть та самая независимость. А ты пока не можешь привести пример такой функции id, которая не будет опираться на поведение и\или состояние и при изменении одного и\или другого перестанет работать.
S>Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится?
Потому что ты над обычной ссылкой на объект можешь настраивать сколько угодной уровней косвенности, но в этом просто нет смысла. В com эта мера вынужденная.
S>>>Забудь про отображение f. Ничего оно никому не дает. G>>В COM дает, ты споришь с фактами. S>В COM используется состояние для сравнения ссылок. Ты тоже споришь с фактами.
Какое состояние?
Ты создай ЛЮБОЙ COM-объет. Получи две ссылки на разные интерфейсы от него. Потом для обоих вызови QueryInterface(IUnknown) и ты получишь одинаковые значения. Где тут состояние?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>Речи не было о том что бы взять совершенно другую идентичность. Я хотел взять немного другую идентичность, которая для некоторых хороших типов, была бы слабже чем штатная. Для всех остальных — ReferenceEquals. Соответственно, для любого наперед неизвестного типа это было бы сравнение ссылок. Для хороших типов типа строк — сравнение значений.
"Для некоторых хороших типов" — зависит от поведения.
S>Собственно вот я все и выложил. Осталось ввернуть пару строк псевдокода: S>
S>bool MyIdentityEquals(object a, object b)
S>{
S> if (ReferenceEquals(a,b))
S> return true; // ослабить а не изменить в корне
S> if (a == null || b == null)
S> return false; // не знаю что определено в штатном порядке, пусть будет так.
S> var type = a.GetType();
S> if (type != b.GetType())
S> return false;
S> if (type == typeof(string) && StringComparer.Ordinal.Equals((string)a, (string)b))
S> return true;
S> // тут обработка хороших типов.
S> if (IsImmutable(type) && IsStructuralEquals(a, b))
S> return true;
S> return false;
S>}
S>
1)Ты явно используешь поведение, когда сравниваешь строки.
2)Ты явно используешь состояние при сравнении. reflection испортит тебе идентичность
3)Есть подозрение что immutable выходит за рамки ООП
И кстати, как ты IsStructuralEquals определишь?
[Immutable]
class A
{
public B B { get; }
}
class B //не-immutable
{
public int Prop {get; set;}
}
var a = new A { B = new B { Prop = 1 } };
var b = new A { B = new B { Prop = 1 } };
Debug.Assert(MyIdentityEquals(a,b)); //Упадет?
b.B.Prop = 1;
Debug.Assert(MyIdentityEquals(a,b)); //А тут?
S>Если это подсунуть вместо штатной ReferenceEquals и забыть про Reflection, который не ООП, то мы останемся в рамках ООП и даже возможно обеспечим некоторую совместимость с ReferenceEquals.
А почему reflection не ООП? Например в самом ООП языке — smalltalk есть рефлексия. И свовйство что изменения в одном объекте сразу отражаются на другом, если объекты идентичны, тоже не говорит какие изменения. Значит в том числе refection.
А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП.
S>Только не говори, что QueryInterface не использует состояние
Ты удивишься, но не использует. Это также явно в спецификации прописано. QueryInterface для объекта должна быть детерминированной функцией, то есть зависеть только от параметров.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>Да, и в таком случае определить функцию дирихле будет тривиально, так как само число при этом будет знать рациональное оно или нет.
Ты вынес задачу из тела функции. Но не значит что решил эту задачу.
G>>>Идентичность для reference-типов в CLR реализуется referenceequals, ты хотел свою идентичность написать, то есть по сути заменить этот referenceequals. S>>Нет, не заменить. Я хотел показать что есть другое отношение идентичности, не совпадающее со сравнением ссылок. G>Это значит что его повсеместно можно использовать вместо referenceequals без изменения результатов работы программы.
Нет, не значит.
S>>Формально COM соответствует OOP но лишь со своим требованием к реализации объектов, которое требует same physical pointer value у реализаций IUnknown. COM identity ослабляет identity, основанное на memory location. Если это требование не выполнить, то получится каша а не OOP. G>Если это требование не выполнить, то получится не COM. То есть COM — ООП.
С оговоркой. Ибо в определении идентичности ООП никаких QueryInterface и IUnknown нет.
S>>Если не эквивалентен другим, тогда понятно. Но это неверно. Идентичность определяет где один объект, а где другой. G>Математически это выглядит как id(a)=id(b), когда a и b — один и тот же объект, id(a)!=id(b), когда a и b — разные объекты. Я уже это формально доказывал. Соответственно нам заранее необходимо знание о разных объектах, иначе любое отношение эквивалентности можно назвать идентичностью.
Знание о разных объектах дает идентичность по определению. Она и только она определяет где идентичные объекты, а где нет. G>Тут нам на помощь приходят свойства G>1)Независимость состояния и поведения
определение G>2)если объекты идентичны, то любое изменение в одном отражается на другом.
следствие
S>>хочешь смотреть на CLR value type — посмотри на COM, где для идентичности сделана оговорка про IUnknown. G>Value type в CLR — не ООП, в COM идентичность определена через QueryInterface(IUnknown). Фактически любая ссылка сводится к "инвариантной", которые уже можно сравнивать для идентичности. Это та функция f, про которую я говорил. G>Соответственно тебе нет смысла доказывать что существует система с какой-то идентичностью если в ней есть такая функция, которая сведет все к сравнению ссылок, так как можно тогда любые ссылки в системе заменить на "инвариантные".
В определении идентичности нет ничего об инвариантности и функции f.
Ладно. Зайдем с другой стороны. Я могу предложить функцию f, которая приняв две различные строки с равным содержимым вернет "инвариантную" ссылку. Значит ли это что две различные строки с разным содержимым стали одним объектом?
S>>>>Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность. G>>>Но value-types — не ооп. Там свойство идентичности, которое говорит о том что для идентичных объектов любое изменение в одном отражается на другом, не выполняется. S>>А если запретить изменения в value типе? Не во всех, а в конкретном? Он станет OOP? G>Нет, идентичность не может быть определена "для конкретного типа", потому что "конкретный тип" это поведение от которого идентичность не должна зависеть.
Идентичность не должна изменяться с изменением состояния и поведения.
S>>Вот тебе задачка про COM, который ООП. Есть у тебя два сырых различных указателя IUnknown*, определи, указывают ли они на один COM объект, не используя состояние и поведение Что бы не было недопонимания, эти указатели могут указывать не на IUnknown грань, а на IDispatch, например. G>QueryInterface(IUnknown) даст равные ссылки, независимо от типа\объекта и его состояния, это требование спецификации COM. Если объект не следует спецификации, то это не COM и соответственно — не ООП.
У тебя два указателя, указывающих на разные места в памяти. Ты еще не знаешь что это COM. Это разные объекты? Когда ты узнаешь что это COM, то тебе оказывается нужно обращаться к поведению этих объектов что бы определить, являются ли они одним объектом. Итого, ты используешь поведение, что бы узнать идентичность.
G>>>>>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
S>>>>А я тебе говорю, что S>>>>1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение. G>>>Бинарное отношение в каком множестве? Видимо "ссылок". S>>
S>>8.2.5 Identity and equality of values
S>>There are two binary operators defined on all pairs of values: identity and equality.
G>Мы только про reference-типы говорим, потому что value-типы — не ООП.
ладно, пусть value не ООП. Но именно определение ECMA указывает, что считать одним объектом а что другим для референсов. С этим будешь спорить?
G>>>Нет ты опять пытаешься опираться на поведение, определяя идентичность через некоторые свойства объекта. Для начала построй идентичность, которая будет для любого типа работать, а потом будем искать f. Если ты найдешь f для какого типа идентичность не появится S>>Ты приводишь в пример COM, а он нарушает твою же трактовку независимости от состояния. G>Нет. Потому что любой объект при QueryInterface(IUnknown) сколько угодно раз должен возвращать одно то же значение, независимо от типа и состояния.
Что бы получить результат QueryInterface(IUnknown), нужно воспользоваться состоянием и поведением, притом полиморфным. G>Это и есть та самая независимость. А ты пока не можешь привести пример такой функции id, которая не будет опираться на поведение и\или состояние и при изменении одного и\или другого перестанет работать.
Да уж, независимость
могу
class A {}
bool MyIdEquals(a, b)
{
if (ReferenceEquals(a, b))
return true;
if (a.GetType() == typeof(A) && b.GetType() == typeof(A))
return true;
return false;
}
S>>Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится? G>Потому что ты над обычной ссылкой на объект можешь настраивать сколько угодной уровней косвенности, но в этом просто нет смысла. В com эта мера вынужденная.
Согласно этой логике две разные строки есть один объект. Но это противоречит identity ECMA. Выбирай, ECMA или f.
S>>>>Забудь про отображение f. Ничего оно никому не дает. G>>>В COM дает, ты споришь с фактами. S>>В COM используется состояние для сравнения ссылок. Ты тоже споришь с фактами. G>Какое состояние?
QueryInterface не из воздуха достает результат, она обращается к состоянию.
G>Ты создай ЛЮБОЙ COM-объет. Получи две ссылки на разные интерфейсы от него. Потом для обоих вызови QueryInterface(IUnknown) и ты получишь одинаковые значения. Где тут состояние?
При вызове QueryInterface используется состояние объекта за ссылкой, используется поведение QueryInterface.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Речи не было о том что бы взять совершенно другую идентичность. Я хотел взять немного другую идентичность, которая для некоторых хороших типов, была бы слабже чем штатная. Для всех остальных — ReferenceEquals. Соответственно, для любого наперед неизвестного типа это было бы сравнение ссылок. Для хороших типов типа строк — сравнение значений. G>"Для некоторых хороших типов" — зависит от поведения.
Как и у QueryInterface
S>>Собственно вот я все и выложил. Осталось ввернуть пару строк псевдокода: S>>
S>>bool MyIdentityEquals(object a, object b)
S>>{
S>> if (ReferenceEquals(a,b))
S>> return true; // ослабить а не изменить в корне
S>> if (a == null || b == null)
S>> return false; // не знаю что определено в штатном порядке, пусть будет так.
S>> var type = a.GetType();
S>> if (type != b.GetType())
S>> return false;
S>> if (type == typeof(string) && StringComparer.Ordinal.Equals((string)a, (string)b))
S>> return true;
S>> // тут обработка хороших типов.
S>> if (IsImmutable(type) && IsStructuralEquals(a, b))
S>> return true;
S>> return false;
S>>}
S>>
G>1)Ты явно используешь поведение, когда сравниваешь строки.
Не беда G>2)Ты явно используешь состояние при сравнении. reflection испортит тебе идентичность
Рефлекшн к черту G>3)Есть подозрение что immutable выходит за рамки ООП
У меня нет. G>И кстати, как ты IsStructuralEquals определишь?
Как-нибудь, в этом нет магии.
G>
G>[Immutable]
G>class A
G>{
G> public B B { get; }
G>}
G>class B //не-immutable
G>{
G> public int Prop {get; set;}
G>}
G>var a = new A { B = new B { Prop = 1 } };
G>var b = new A { B = new B { Prop = 1 } };
G>Debug.Assert(MyIdentityEquals(a,b)); //Упадет?
G>b.B.Prop = 1;
G>Debug.Assert(MyIdentityEquals(a,b)); //А тут?
G>
Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду.
S>>Если это подсунуть вместо штатной ReferenceEquals и забыть про Reflection, который не ООП, то мы останемся в рамках ООП и даже возможно обеспечим некоторую совместимость с ReferenceEquals. G>А почему reflection не ООП? Например в самом ООП языке — smalltalk есть рефлексия. И свовйство что изменения в одном объекте сразу отражаются на другом, если объекты идентичны, тоже не говорит какие изменения. Значит в том числе refection.
Я уже писал, что рефлексия в дотнете ломает инкапсуляцию данных. G>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП.
Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП
S>>Только не говори, что QueryInterface не использует состояние G>Ты удивишься, но не использует. Это также явно в спецификации прописано. QueryInterface для объекта должна быть детерминированной функцией, то есть зависеть только от параметров.
Не поверишь, функция, сравнивающая две строки, тоже может быть детерминированной, т.е. зависеть только от параметров. По твоей же логике детерминированная функция не использует состояние. Значит сравнивать строки можно не используя состояние.
Наверное тогда можно сравнивать все объекты с детерминированными функциями (иммутабельные) не опираясь на состояние
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>Да, и в таком случае определить функцию дирихле будет тривиально, так как само число при этом будет знать рациональное оно или нет. S>Ты вынес задачу из тела функции. Но не значит что решил эту задачу.
Ты же просил записать функцию дирихле на C# я записал. В чем вопрос?
S>>>Формально COM соответствует OOP но лишь со своим требованием к реализации объектов, которое требует same physical pointer value у реализаций IUnknown. COM identity ослабляет identity, основанное на memory location. Если это требование не выполнить, то получится каша а не OOP. G>>Если это требование не выполнить, то получится не COM. То есть COM — ООП. S>С оговоркой. Ибо в определении идентичности ООП никаких QueryInterface и IUnknown нет.
Считай что функция ID для COM выглядит как QueryIntrerface(IUnknown). Сравнение в дальнейшем работает со ссылками.
В принципе ничто не мешает при работе с COM всегда держать ссылку на IUnknown и выполнять запрос нужного интерфейса при вызове метода. Тогда идентичность сведется к простому сравнению ссылок.
Поэтому все случаи приводимости к сравнению ссылок можно считать эквивалентными.
S>>>Если не эквивалентен другим, тогда понятно. Но это неверно. Идентичность определяет где один объект, а где другой. G>>Математически это выглядит как id(a)=id(b), когда a и b — один и тот же объект, id(a)!=id(b), когда a и b — разные объекты. Я уже это формально доказывал. Соответственно нам заранее необходимо знание о разных объектах, иначе любое отношение эквивалентности можно назвать идентичностью. S>Знание о разных объектах дает идентичность по определению. Она и только она определяет где идентичные объекты, а где нет.
Нет, объекты могут быть разные, даже если ты как сторонний наблюдатель не можешь их различить. Пример — строки в БД, совпадающие по значения колонок.
Требование ООП — умения стороннему наблюдателю различать разные объекты.
Метафора из жизни: близнецы — ты как сторонний наблюдатель не можешь отличить одного от другого, но это разные люди.
S>Ладно. Зайдем с другой стороны. Я могу предложить функцию f, которая приняв две различные строки с равным содержимым вернет "инвариантную" ссылку. Значит ли это что две различные строки с разным содержимым стали одним объектом?
Нет, ты опять пытаешься искать приводимость к ссылкам до того как придумал идентичность, отличающуюся от сравнения ссылок.
Кроме того функция f, как и сама идентичность должна не опираться на состояние и поведение (конкретные типы). Что у тебя явно нарушается.
Ты вообще сам не заметил, что постоянно пытаешься "расширить" эквивалентность до идентичности, только все время приплетая состояние и\или поведение.
S>>>>>Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность. G>>>>Но value-types — не ооп. Там свойство идентичности, которое говорит о том что для идентичных объектов любое изменение в одном отражается на другом, не выполняется. S>>>А если запретить изменения в value типе? Не во всех, а в конкретном? Он станет OOP? G>>Нет, идентичность не может быть определена "для конкретного типа", потому что "конкретный тип" это поведение от которого идентичность не должна зависеть. S>Идентичность не должна изменяться с изменением состояния и поведения.
Это уже твои домыслы. В определении написано "независимо", то есть вообще никак.
S>>>Вот тебе задачка про COM, который ООП. Есть у тебя два сырых различных указателя IUnknown*, определи, указывают ли они на один COM объект, не используя состояние и поведение Что бы не было недопонимания, эти указатели могут указывать не на IUnknown грань, а на IDispatch, например. G>>QueryInterface(IUnknown) даст равные ссылки, независимо от типа\объекта и его состояния, это требование спецификации COM. Если объект не следует спецификации, то это не COM и соответственно — не ООП. S>У тебя два указателя, указывающих на разные места в памяти. Ты еще не знаешь что это COM. Это разные объекты?
А что такое объект тогда? Мы работаем в конкретной системе, будь то CLR, или COM, или что что ты сам выдумаешь. И мы заранее знаем что у нас есть "объект" в это системе. И мы заранее имеем некоторый объект, для которого хотим получить id.
Остальное — демагогия.
Ты сначала определи систему, потом идентичность в ней.
G>>>>>>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
S>>>>>А я тебе говорю, что S>>>>>1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение. G>>>>Бинарное отношение в каком множестве? Видимо "ссылок". S>>>
S>>>8.2.5 Identity and equality of values
S>>>There are two binary operators defined on all pairs of values: identity and equality.
G>>Мы только про reference-типы говорим, потому что value-типы — не ООП. S>ладно, пусть value не ООП. Но именно определение ECMA указывает, что считать одним объектом а что другим для референсов. С этим будешь спорить?
Нет. Читай его внимательно. Там не написано что такое разные объекты, там написано про идентичность и эквивалентность.
Вообще бывают разные объекты, даже если ты их не умеешь различать (то есть у них нет identity).
S>Что бы получить результат QueryInterface(IUnknown), нужно воспользоваться состоянием и поведением, притом полиморфным.
Каким состоянием? Каким поведением?
G>>Это и есть та самая независимость. А ты пока не можешь привести пример такой функции id, которая не будет опираться на поведение и\или состояние и при изменении одного и\или другого перестанет работать. S>Да уж, независимость S>могу S>
S>class A {}
S>bool MyIdEquals(a, b)
S>{
S> if (ReferenceEquals(a, b))
S> return true;
S> if (a.GetType() == typeof(A) && b.GetType() == typeof(A))
S> return true;
S> return false;
S>}
S>
Типы — поведение (или состояние, если рассматривать как ссылку на VMT). в COM QueryInterface имеет одни и те же правила работы, независимо то типа.
S>>>Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится? G>>Потому что ты над обычной ссылкой на объект можешь настраивать сколько угодной уровней косвенности, но в этом просто нет смысла. В com эта мера вынужденная. S>Согласно этой логике две разные строки есть один объект. Но это противоречит identity ECMA. Выбирай, ECMA или f.
В ECMA это не нужно, там уже можно ссылки сравнивать. Хотя твои размышления натолкнули на мысль что f таки должна быть обратима. Надо более точно сформулировать.
S>>>>>Забудь про отображение f. Ничего оно никому не дает. G>>>>В COM дает, ты споришь с фактами. S>>>В COM используется состояние для сравнения ссылок. Ты тоже споришь с фактами. G>>Какое состояние? S>QueryInterface не из воздуха достает результат, она обращается к состоянию.
Не обращается. QueryInterface — детерминированная функция.
G>>Ты создай ЛЮБОЙ COM-объет. Получи две ссылки на разные интерфейсы от него. Потом для обоих вызови QueryInterface(IUnknown) и ты получишь одинаковые значения. Где тут состояние? S>При вызове QueryInterface используется состояние объекта за ссылкой, используется поведение QueryInterface.
Еще раз: такое поведение у любого объекта. Это особенность самого COM. как сравнение ссылок в CLR.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>Речи не было о том что бы взять совершенно другую идентичность. Я хотел взять немного другую идентичность, которая для некоторых хороших типов, была бы слабже чем штатная. Для всех остальных — ReferenceEquals. Соответственно, для любого наперед неизвестного типа это было бы сравнение ссылок. Для хороших типов типа строк — сравнение значений. G>>"Для некоторых хороших типов" — зависит от поведения. S>Как и у QueryInterface
Нет, в СOM у любого объекта так работает QueryInterface, более того это детерминированная функция.
S>>>Собственно вот я все и выложил. Осталось ввернуть пару строк псевдокода: S>>>
S>>>bool MyIdentityEquals(object a, object b)
S>>>{
S>>> if (ReferenceEquals(a,b))
S>>> return true; // ослабить а не изменить в корне
S>>> if (a == null || b == null)
S>>> return false; // не знаю что определено в штатном порядке, пусть будет так.
S>>> var type = a.GetType();
S>>> if (type != b.GetType())
S>>> return false;
S>>> if (type == typeof(string) && StringComparer.Ordinal.Equals((string)a, (string)b))
S>>> return true;
S>>> // тут обработка хороших типов.
S>>> if (IsImmutable(type) && IsStructuralEquals(a, b))
S>>> return true;
S>>> return false;
S>>>}
S>>>
G>>1)Ты явно используешь поведение, когда сравниваешь строки. S>Не беда
Но это противоречит определению.
G>>2)Ты явно используешь состояние при сравнении. reflection испортит тебе идентичность S>Рефлекшн к черту
Счегобы?
G>>3)Есть подозрение что immutable выходит за рамки ООП S>У меня нет. G>>И кстати, как ты IsStructuralEquals определишь? S>Как-нибудь, в этом нет магии.
Дьявол в деталях.
G>>
G>>[Immutable]
G>>class A
G>>{
G>> public B B { get; }
G>>}
G>>class B //не-immutable
G>>{
G>> public int Prop {get; set;}
G>>}
G>>var a = new A { B = new B { Prop = 1 } };
G>>var b = new A { B = new B { Prop = 1 } };
G>>Debug.Assert(MyIdentityEquals(a,b)); //Упадет?
G>>b.B.Prop = 1;
G>>Debug.Assert(MyIdentityEquals(a,b)); //А тут?
G>>
S>Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду.
Неважно, скажи как отработает в данном коде.
S>>>Если это подсунуть вместо штатной ReferenceEquals и забыть про Reflection, который не ООП, то мы останемся в рамках ООП и даже возможно обеспечим некоторую совместимость с ReferenceEquals. G>>А почему reflection не ООП? Например в самом ООП языке — smalltalk есть рефлексия. И свовйство что изменения в одном объекте сразу отражаются на другом, если объекты идентичны, тоже не говорит какие изменения. Значит в том числе refection. S>Я уже писал, что рефлексия в дотнете ломает инкапсуляцию данных.
И что? ООП — объекты с identity и передача сообщений. Пусть ломает, она при этом никак ООП не противоречит.
G>>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП. S>Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП
нет, иммутабельная строка не заставляет быть иммутабельными все объекты, а твоя функция IsStructuralEquals будет работать только есть объекты состоят из иммутабельных объектов. Это будет не ООП.
S>>>Только не говори, что QueryInterface не использует состояние G>>Ты удивишься, но не использует. Это также явно в спецификации прописано. QueryInterface для объекта должна быть детерминированной функцией, то есть зависеть только от параметров. S>Не поверишь, функция, сравнивающая две строки, тоже может быть детерминированной, т.е. зависеть только от параметров. По твоей же логике детерминированная функция не использует состояние. Значит сравнивать строки можно не используя состояние.
Да пусть сравнивает, причем тут идентичность?
Ты пойми что требование QueryInterface возвращать одну и ту же ссылку не зависит от того какой класс реализует.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>Да, и в таком случае определить функцию дирихле будет тривиально, так как само число при этом будет знать рациональное оно или нет. S>>Ты вынес задачу из тела функции. Но не значит что решил эту задачу. G>Ты же просил записать функцию дирихле на C# я записал. В чем вопрос?
Ты просил функцию MyIdEquals, я записал.
S>>>>Формально COM соответствует OOP но лишь со своим требованием к реализации объектов, которое требует same physical pointer value у реализаций IUnknown. COM identity ослабляет identity, основанное на memory location. Если это требование не выполнить, то получится каша а не OOP. G>>>Если это требование не выполнить, то получится не COM. То есть COM — ООП. S>>С оговоркой. Ибо в определении идентичности ООП никаких QueryInterface и IUnknown нет. G>Считай что функция ID для COM выглядит как QueryIntrerface(IUnknown). Сравнение в дальнейшем работает со ссылками.
Считай что функция сравнения для строк выглядит GetInvariantString
G>В принципе ничто не мешает при работе с COM всегда держать ссылку на IUnknown и выполнять запрос нужного интерфейса при вызове метода. Тогда идентичность сведется к простому сравнению ссылок.
Ничего не мешает для строк держать ссылку на интернированную строку
G>Поэтому все случаи приводимости к сравнению ссылок можно считать эквивалентными.
Это делает разные строки идентичными по ECMA?
S>>>>Если не эквивалентен другим, тогда понятно. Но это неверно. Идентичность определяет где один объект, а где другой. G>>>Математически это выглядит как id(a)=id(b), когда a и b — один и тот же объект, id(a)!=id(b), когда a и b — разные объекты. Я уже это формально доказывал. Соответственно нам заранее необходимо знание о разных объектах, иначе любое отношение эквивалентности можно назвать идентичностью. S>>Знание о разных объектах дает идентичность по определению. Она и только она определяет где идентичные объекты, а где нет. G>Нет, объекты могут быть разные, даже если ты как сторонний наблюдатель не можешь их различить. Пример — строки в БД, совпадающие по значения колонок. G>Требование ООП — умения стороннему наблюдателю различать разные объекты.
Идентичность говорит где разные объекты, а где нет. Она так говорит в ECMA, хочешь ты того или нет. Она так говорит для COM.
G>Метафора из жизни: близнецы — ты как сторонний наблюдатель не можешь отличить одного от другого, но это разные люди.
Метафора ничего не доказывает в отношении идентичности. И COM твою метафору опровергает. Ты видишь двух разных людей IUnknown*, а они — одно целое.
S>>Ладно. Зайдем с другой стороны. Я могу предложить функцию f, которая приняв две различные строки с равным содержимым вернет "инвариантную" ссылку. Значит ли это что две различные строки с разным содержимым стали одним объектом? G>Нет, ты опять пытаешься искать приводимость к ссылкам до того как придумал идентичность, отличающуюся от сравнения ссылок. G>Кроме того функция f, как и сама идентичность должна не опираться на состояние и поведение (конкретные типы). Что у тебя явно нарушается.
реализация QueryInterface типонезависима?
G>Ты вообще сам не заметил, что постоянно пытаешься "расширить" эквивалентность до идентичности, только все время приплетая состояние и\или поведение.
Как в COM
S>>Идентичность не должна изменяться с изменением состояния и поведения. G>Это уже твои домыслы. В определении написано "независимо", то есть вообще никак.
Но в COM приходится обращаться к полиморфным функциям и ты это считаешь независимым
S>>>>Вот тебе задачка про COM, который ООП. Есть у тебя два сырых различных указателя IUnknown*, определи, указывают ли они на один COM объект, не используя состояние и поведение Что бы не было недопонимания, эти указатели могут указывать не на IUnknown грань, а на IDispatch, например. G>>>QueryInterface(IUnknown) даст равные ссылки, независимо от типа\объекта и его состояния, это требование спецификации COM. Если объект не следует спецификации, то это не COM и соответственно — не ООП. S>>У тебя два указателя, указывающих на разные места в памяти. Ты еще не знаешь что это COM. Это разные объекты? G>А что такое объект тогда? Мы работаем в конкретной системе, будь то CLR, или COM, или что что ты сам выдумаешь. И мы заранее знаем что у нас есть "объект" в это системе. И мы заранее имеем некоторый объект, для которого хотим получить id.
Ну вот, заранее кто тебе сказал что такое есть "объект" и в каком месте он отличается от других? G>Остальное — демагогия. G>Ты сначала определи систему, потом идентичность в ней.
Берем C++ и два указателя на IUnknown*. Они указывают на один объект?
G>>>Мы только про reference-типы говорим, потому что value-типы — не ООП. S>>ладно, пусть value не ООП. Но именно определение ECMA указывает, что считать одним объектом а что другим для референсов. С этим будешь спорить? G>Нет. Читай его внимательно. Там не написано что такое разные объекты, там написано про идентичность и эквивалентность.
Там написано про идентичность значений, в частности какие считать идентичными, а какие нет. Про эквивалентность не там. G>Вообще бывают разные объекты, даже если ты их не умеешь различать (то есть у них нет identity).
Слушай, если уж value-типы с identity ты назвал не ООП, то объекты без identity-то, уж наверняка не ООП? Или как?
S>>Что бы получить результат QueryInterface(IUnknown), нужно воспользоваться состоянием и поведением, притом полиморфным. G>Каким состоянием? Каким поведением?
QI это полиморфная функция. взять результат она может только обращаясь к состоянию. Обеспечить детерминированность она может только обращаясь к состоянию. Или ты знаешь другие варианты?
G>>>Это и есть та самая независимость. А ты пока не можешь привести пример такой функции id, которая не будет опираться на поведение и\или состояние и при изменении одного и\или другого перестанет работать. S>>Да уж, независимость S>>могу S>>
S>>class A {}
S>>bool MyIdEquals(a, b)
S>>{
S>> if (ReferenceEquals(a, b))
S>> return true;
S>> if (a.GetType() == typeof(A) && b.GetType() == typeof(A))
S>> return true;
S>> return false;
S>>}
S>>
G>Типы — поведение (или состояние, если рассматривать как ссылку на VMT). в COM QueryInterface имеет одни и те же правила работы, независимо то типа.
И что? Разве это где-то упомянуто в определении идентити, а я не заметил?
S>>>>Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится? G>>>Потому что ты над обычной ссылкой на объект можешь настраивать сколько угодной уровней косвенности, но в этом просто нет смысла. В com эта мера вынужденная. S>>Согласно этой логике две разные строки есть один объект. Но это противоречит identity ECMA. Выбирай, ECMA или f. G>В ECMA это не нужно, там уже можно ссылки сравнивать. Хотя твои размышления натолкнули на мысль что f таки должна быть обратима. Надо более точно сформулировать.
Про обратимость f я тебе уже свои размышления показывал. Они привели к противоречию существования такой обратимой f.
S>>>>>>Забудь про отображение f. Ничего оно никому не дает. G>>>>>В COM дает, ты споришь с фактами. S>>>>В COM используется состояние для сравнения ссылок. Ты тоже споришь с фактами. G>>>Какое состояние? S>>QueryInterface не из воздуха достает результат, она обращается к состоянию. G>Не обращается. QueryInterface — детерминированная функция.
StringComparer.Ordinal.Equals тоже детерминированная функция. Не пойму, куда ты клонишь? Детермизированная функция — не значит что не обращается к состоянию. Я могу написать детерминированную функцию, которая мало что обращается, так и изменяет его:
public int callCount;
public int Add(int x, int y)
{
callCount++;
return x + y;
}
G>>>Ты создай ЛЮБОЙ COM-объет. Получи две ссылки на разные интерфейсы от него. Потом для обоих вызови QueryInterface(IUnknown) и ты получишь одинаковые значения. Где тут состояние? S>>При вызове QueryInterface используется состояние объекта за ссылкой, используется поведение QueryInterface. G>Еще раз: такое поведение у любого объекта. Это особенность самого COM. как сравнение ссылок в CLR.
Ну и что? MyIdEquals определяет identity для любого объекта. Это особенность MyIdEquals.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>>>Речи не было о том что бы взять совершенно другую идентичность. Я хотел взять немного другую идентичность, которая для некоторых хороших типов, была бы слабже чем штатная. Для всех остальных — ReferenceEquals. Соответственно, для любого наперед неизвестного типа это было бы сравнение ссылок. Для хороших типов типа строк — сравнение значений. G>>>"Для некоторых хороших типов" — зависит от поведения. S>>Как и у QueryInterface G>Нет, в СOM у любого объекта так работает QueryInterface, более того это детерминированная функция.
Уже отвечал. Детерминированность не означает не обращения к состоянию и поведению.
S>>>>Собственно вот я все и выложил. Осталось ввернуть пару строк псевдокода: S>>>>
S>>>>bool MyIdentityEquals(object a, object b)
S>>>>{
S>>>> if (ReferenceEquals(a,b))
S>>>> return true; // ослабить а не изменить в корне
S>>>> if (a == null || b == null)
S>>>> return false; // не знаю что определено в штатном порядке, пусть будет так.
S>>>> var type = a.GetType();
S>>>> if (type != b.GetType())
S>>>> return false;
S>>>> if (type == typeof(string) && StringComparer.Ordinal.Equals((string)a, (string)b))
S>>>> return true;
S>>>> // тут обработка хороших типов.
S>>>> if (IsImmutable(type) && IsStructuralEquals(a, b))
S>>>> return true;
S>>>> return false;
S>>>>}
S>>>>
G>>>1)Ты явно используешь поведение, когда сравниваешь строки. S>>Не беда G>Но это противоречит определению.
QueryInterface тоже
G>>>2)Ты явно используешь состояние при сравнении. reflection испортит тебе идентичность S>>Рефлекшн к черту G>Счегобы?
Я утверждаю что это не ООП инструмент.
G>>>3)Есть подозрение что immutable выходит за рамки ООП S>>У меня нет. G>>>И кстати, как ты IsStructuralEquals определишь? S>>Как-нибудь, в этом нет магии. G>Дьявол в деталях.
Я думаю что это неважно. Пусть хоть рефлексией по полям или через memcmp.
G>>>
G>>>[Immutable]
G>>>class A
G>>>{
G>>> public B B { get; }
G>>>}
G>>>class B //не-immutable
G>>>{
G>>> public int Prop {get; set;}
G>>>}
G>>>var a = new A { B = new B { Prop = 1 } };
G>>>var b = new A { B = new B { Prop = 1 } };
G>>>Debug.Assert(MyIdentityEquals(a,b)); //Упадет?
G>>>b.B.Prop = 1;
G>>>Debug.Assert(MyIdentityEquals(a,b)); //А тут?
G>>>
S>>Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду. G>Неважно, скажи как отработает в данном коде.
В идеале она посчитает что объекты мутабельны и вернет false.
S>>>>Если это подсунуть вместо штатной ReferenceEquals и забыть про Reflection, который не ООП, то мы останемся в рамках ООП и даже возможно обеспечим некоторую совместимость с ReferenceEquals. G>>>А почему reflection не ООП? Например в самом ООП языке — smalltalk есть рефлексия. И свовйство что изменения в одном объекте сразу отражаются на другом, если объекты идентичны, тоже не говорит какие изменения. Значит в том числе refection. S>>Я уже писал, что рефлексия в дотнете ломает инкапсуляцию данных. G>И что? ООП — объекты с identity и передача сообщений. Пусть ломает, она при этом никак ООП не противоречит.
Хм, слушай, я возьму в руки рефлексию и окажется что твои объекты вообще сообщений не получали, и даже не тех типов, что ты о них думал когда создавал. Или окажется что один из объектов лежит внутри памяти другого объекта и чутко реагирует на сообщения внешнего. Вот будет веселуха, а не ООП
G>>>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП. S>>Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП G>нет, иммутабельная строка не заставляет быть иммутабельными все объекты, а твоя функция IsStructuralEquals будет работать только есть объекты состоят из иммутабельных объектов. Это будет не ООП.
На каком основании? Где написано что иммутабельный объект не объект?
S>>>>Только не говори, что QueryInterface не использует состояние G>>>Ты удивишься, но не использует. Это также явно в спецификации прописано. QueryInterface для объекта должна быть детерминированной функцией, то есть зависеть только от параметров. S>>Не поверишь, функция, сравнивающая две строки, тоже может быть детерминированной, т.е. зависеть только от параметров. По твоей же логике детерминированная функция не использует состояние. Значит сравнивать строки можно не используя состояние. G>Да пусть сравнивает, причем тут идентичность? G>Ты пойми что требование QueryInterface возвращать одну и ту же ссылку не зависит от того какой класс реализует.
Причем тут это? QI использует состояние. Это был твой аргумент против сравнения объектов. Оказалось что QI использовать состояние можно, а при сравнении строк — нельзя.
Здравствуйте, samius, Вы писали:
S>Ты просил функцию MyIdEquals, я записал.
Она не является она не выполняет сравнение identity ни в одной известной мне ООП системе.
G>>Считай что функция ID для COM выглядит как QueryIntrerface(IUnknown). Сравнение в дальнейшем работает со ссылками. S>Считай что функция сравнения для строк выглядит GetInvariantString
Ты определяешь функцию только для строки (опираешься на поведение), а QueryIntrerface(IUnknown) работает для любого COM-объекта.
G>>В принципе ничто не мешает при работе с COM всегда держать ссылку на IUnknown и выполнять запрос нужного интерфейса при вызове метода. Тогда идентичность сведется к простому сравнению ссылок. S>Ничего не мешает для строк держать ссылку на интернированную строку
да, и тогда сравнение строк всегда можно заменить сравнением ссылок. Но так не делают по соображениям быстродействия.
G>>Поэтому все случаи приводимости к сравнению ссылок можно считать эквивалентными. S>Это делает разные строки идентичными по ECMA?
Нет. Потому что идентичность в ECMA уже определена по-другому. Хотя если на уровне реализации сделать интернирование каждой строки, то таки да, любые эквивалентные строки будут идентичными.
G>>Требование ООП — умения стороннему наблюдателю различать разные объекты. S>Идентичность говорит где разные объекты, а где нет.
Она позволяет стороннему наблюдателю различить разные объекты. Но не является критерием разных объектов.
То есть чтобы объекты были разными достаточно разных identity, но это не является необходимым условием.
G>>Метафора из жизни: близнецы — ты как сторонний наблюдатель не можешь отличить одного от другого, но это разные люди. S>Метафора ничего не доказывает в отношении идентичности. И COM твою метафору опровергает. Ты видишь двух разных людей IUnknown*, а они — одно целое.
Наоборот, если ты видишь два объекта у которых QueryIntrerface(IUnknown) совпадают, то это один объект, не совпадают — разные. COM как раз подтверждает.
Ты видишь двух людей (не одновременно), спрашиваешь у них СНИЛС\SSN — не совпадают, значит люди разные, а совпадают — это один человек.
S>>>Ладно. Зайдем с другой стороны. Я могу предложить функцию f, которая приняв две различные строки с равным содержимым вернет "инвариантную" ссылку. Значит ли это что две различные строки с разным содержимым стали одним объектом? G>>Нет, ты опять пытаешься искать приводимость к ссылкам до того как придумал идентичность, отличающуюся от сравнения ссылок. G>>Кроме того функция f, как и сама идентичность должна не опираться на состояние и поведение (конкретные типы). Что у тебя явно нарушается. S>реализация QueryInterface типонезависима?
Это зависит от самого компонента, но поведение, то есть то что ты можешь видеть снаружи — да, не зависит от типа.
G>>Ты вообще сам не заметил, что постоянно пытаешься "расширить" эквивалентность до идентичности, только все время приплетая состояние и\или поведение. S>Как в COM
Нет, там таких проблем нет.
Return a pointer within this object instance that implements the indicated interface. Answer NULL if the receiver does not contain an implementation of the interface.
It is required that any query for the specific interface IUnknown always returns the same
actual pointer value, no matter through which interface derived from IUnknown it is called.
This enables the following identity test algorithm to determine whether two pointers in
fact point to the same object: call QueryInterface(IID_IUnknown, ...) on both and compare the results.
... This requirement isthe basis for what is called COM identity.
Явно черным по английскому сказано что это и есть identity.
S>>>Идентичность не должна изменяться с изменением состояния и поведения. G>>Это уже твои домыслы. В определении написано "независимо", то есть вообще никак. S>Но в COM приходится обращаться к полиморфным функциям и ты это считаешь независимым
Наблюдаемое поведение не зависит от конкретного типа.
S>Берем C++ и два указателя на IUnknown*. Они указывают на один объект?
Если не совпадают, то нет.
G>>>>Мы только про reference-типы говорим, потому что value-типы — не ООП. S>>>ладно, пусть value не ООП. Но именно определение ECMA указывает, что считать одним объектом а что другим для референсов. С этим будешь спорить? G>>Нет. Читай его внимательно. Там не написано что такое разные объекты, там написано про идентичность и эквивалентность. S>Там написано про идентичность значений, в частности какие считать идентичными, а какие нет. Про эквивалентность не там. G>>Вообще бывают разные объекты, даже если ты их не умеешь различать (то есть у них нет identity). S>Слушай, если уж value-типы с identity ты назвал не ООП, то объекты без identity-то, уж наверняка не ООП? Или как?
Да, требование ООП чтобы у разных объектов были разные identity. Про разные объекты см выше.
S>>>Что бы получить результат QueryInterface(IUnknown), нужно воспользоваться состоянием и поведением, притом полиморфным. G>>Каким состоянием? Каким поведением? S>QI это полиморфная функция. взять результат она может только обращаясь к состоянию. Обеспечить детерминированность она может только обращаясь к состоянию. Или ты знаешь другие варианты?
Реализация не важна (ты же по сути не знаешь что внутри делает object.ReferenceEquals), важно наблюдаемое снаружи поведение, так во оно в случае QueryInterface(IUnknown) совпадает у всех COM объектов.
G>>>>Это и есть та самая независимость. А ты пока не можешь привести пример такой функции id, которая не будет опираться на поведение и\или состояние и при изменении одного и\или другого перестанет работать. S>>>Да уж, независимость S>>>могу S>>>
S>>>class A {}
S>>>bool MyIdEquals(a, b)
S>>>{
S>>> if (ReferenceEquals(a, b))
S>>> return true;
S>>> if (a.GetType() == typeof(A) && b.GetType() == typeof(A))
S>>> return true;
S>>> return false;
S>>>}
S>>>
G>>Типы — поведение (или состояние, если рассматривать как ссылку на VMT). в COM QueryInterface имеет одни и те же правила работы, независимо то типа. S>И что? Разве это где-то упомянуто в определении идентити, а я не заметил?
Типы — поведение (или состояние, если рассматривать как ссылку на VMT\type), ты именно их используешь в своем коде/
S>>>>>Не пойму, откуда взялась такая функция и почему она будет говорить что идентичность не появится? G>>>>Потому что ты над обычной ссылкой на объект можешь настраивать сколько угодной уровней косвенности, но в этом просто нет смысла. В com эта мера вынужденная. S>>>Согласно этой логике две разные строки есть один объект. Но это противоречит identity ECMA. Выбирай, ECMA или f. G>>В ECMA это не нужно, там уже можно ссылки сравнивать. Хотя твои размышления натолкнули на мысль что f таки должна быть обратима. Надо более точно сформулировать. S>Про обратимость f я тебе уже свои размышления показывал. Они привели к противоречию существования такой обратимой f.
Я еще не сформулировал в каком смысле нужна обратимость.
G>>>>Ты создай ЛЮБОЙ COM-объет. Получи две ссылки на разные интерфейсы от него. Потом для обоих вызови QueryInterface(IUnknown) и ты получишь одинаковые значения. Где тут состояние? S>>>При вызове QueryInterface используется состояние объекта за ссылкой, используется поведение QueryInterface. G>>Еще раз: такое поведение у любого объекта. Это особенность самого COM. как сравнение ссылок в CLR. S>Ну и что? MyIdEquals определяет identity для любого объекта. Это особенность MyIdEquals.
Нет, внутрь MyIdEquals заложено знание о конкретных классах, в отличие от QueryInterface.
Здравствуйте, samius, Вы писали:
G>>>>1)Ты явно используешь поведение, когда сравниваешь строки. S>>>Не беда G>>Но это противоречит определению. S>QueryInterface тоже
Не-а. http://www.daimi.au.dk/~datpete/COT/COM_SPEC/pdf/com_spec.pdf
Пункт 3.3.1.1
G>>>>2)Ты явно используешь состояние при сравнении. reflection испортит тебе идентичность S>>>Рефлекшн к черту G>>Счегобы? S>Я утверждаю что это не ООП инструмент.
Утверждай дальше, но это не так. Reflecton нигде не противоречит OOP.
Даже Алан Кей, создатель ООП и языка SmallTalk включил туда reflection.
Можешь найти хоть одно авторитетное мнение, совпадающее с твоим?
G>>>>
G>>>>[Immutable]
G>>>>class A
G>>>>{
G>>>> public B B { get; }
G>>>>}
G>>>>class B //не-immutable
G>>>>{
G>>>> public int Prop {get; set;}
G>>>>}
G>>>>var a = new A { B = new B { Prop = 1 } };
G>>>>var b = new A { B = new B { Prop = 1 } };
G>>>>Debug.Assert(MyIdentityEquals(a,b)); //Упадет?
G>>>>b.B.Prop = 1;
G>>>>Debug.Assert(MyIdentityEquals(a,b)); //А тут?
G>>>>
S>>>Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду. G>>Неважно, скажи как отработает в данном коде. S>В идеале она посчитает что объекты мутабельны и вернет false.
Отлично, то есть чтобы MyIdentityEquals возвращало true требуется "глубокая" immutability. Это будет не ооп.
G>>>>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП. S>>>Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП G>>нет, иммутабельная строка не заставляет быть иммутабельными все объекты, а твоя функция IsStructuralEquals будет работать только есть объекты состоят из иммутабельных объектов. Это будет не ООП. S>На каком основании? Где написано что иммутабельный объект не объект?
Нигде, но на глубокой иммутабельности у тебя не получится ООП.
S>Причем тут это? QI использует состояние.
Не использует.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Ты просил функцию MyIdEquals, я записал. G>Она не является она не выполняет сравнение identity ни в одной известной мне ООП системе.
Это не является критерием identity.
G>Ты определяешь функцию только для строки (опираешься на поведение), а QueryIntrerface(IUnknown) работает для любого COM-объекта.
Для каждого по-своему. И как именно — определяется реализацией IUnknown той сущности, у которой ты вызваешь QI.
G>>>В принципе ничто не мешает при работе с COM всегда держать ссылку на IUnknown и выполнять запрос нужного интерфейса при вызове метода. Тогда идентичность сведется к простому сравнению ссылок. S>>Ничего не мешает для строк держать ссылку на интернированную строку G>да, и тогда сравнение строк всегда можно заменить сравнением ссылок. Но так не делают по соображениям быстродействия.
Соображения быстродействия не являются определяющими в критериях принадлежности идентити ООП.
G>>>Поэтому все случаи приводимости к сравнению ссылок можно считать эквивалентными. S>>Это делает разные строки идентичными по ECMA? G>Нет. Потому что идентичность в ECMA уже определена по-другому. Хотя если на уровне реализации сделать интернирование каждой строки, то таки да, любые эквивалентные строки будут идентичными.
Что-то я не понял. Есть функция f, которая RefEquals(f(a), f(b)) возвращает true. И ты считаешь строки не идентичными?
G>>>Требование ООП — умения стороннему наблюдателю различать разные объекты. S>>Идентичность говорит где разные объекты, а где нет. G>Она позволяет стороннему наблюдателю различить разные объекты. Но не является критерием разных объектов. G>То есть чтобы объекты были разными достаточно разных identity, но это не является необходимым условием.
т.е. same id => same object но не same id <= same object? Т.е.один объект дает разные identity?
Ты только что сломал детерминированность и рефлексивность id.
G>>>Метафора из жизни: близнецы — ты как сторонний наблюдатель не можешь отличить одного от другого, но это разные люди. S>>Метафора ничего не доказывает в отношении идентичности. И COM твою метафору опровергает. Ты видишь двух разных людей IUnknown*, а они — одно целое. G>Наоборот, если ты видишь два объекта у которых QueryIntrerface(IUnknown) совпадают, то это один объект, не совпадают — разные. COM как раз подтверждает.
COM как раз учит различать свои объекты, дополняя location identity, т.е. ослабляя его. G>Ты видишь двух людей (не одновременно), спрашиваешь у них СНИЛС\SSN — не совпадают, значит люди разные, а совпадают — это один человек.
Я больше поверю тому что вижу, а не тому что они ответят
G>>>Кроме того функция f, как и сама идентичность должна не опираться на состояние и поведение (конкретные типы). Что у тебя явно нарушается. S>>реализация QueryInterface типонезависима? G>Это зависит от самого компонента, но поведение, то есть то что ты можешь видеть снаружи — да, не зависит от типа.
Возможно я понял, о чем ты. Но где в определении идентити ООП сказано об этом?
G>>>Ты вообще сам не заметил, что постоянно пытаешься "расширить" эквивалентность до идентичности, только все время приплетая состояние и\или поведение. S>>Как в COM G>Нет, там таких проблем нет.
Без состояния не вернуть QI(IID_IUnknown).
G>Вообще читай спеку, ты опять пытаешься спорить с фактами: G>http://www.daimi.au.dk/~datpete/COT/COM_SPEC/pdf/com_spec.pdf
G>
G>3 . 3 . 1 . 1 IUnknown:
G>HRESULT IUnknown::QueryInterface(iid, ppv)
G>Return a pointer within this object instance that implements the indicated interface. Answer NULL if the receiver does not contain an implementation of the interface.
G>It is required that any query for the specific interface IUnknown always returns the same
G>actual pointer value, no matter through which interface derived from IUnknown it is called.
G>This enables the following identity test algorithm to determine whether two pointers in
G>fact point to the same object: call QueryInterface(IID_IUnknown, ...) on both and compare the results.
G>
G>...
G>This requirement isthe basis for what is called COM identity.
G>Явно черным по английскому сказано что это и есть identity.
Которая опирается на состояние и поведение (это не сказано, но это очевидно).
S>>>>Идентичность не должна изменяться с изменением состояния и поведения. G>>>Это уже твои домыслы. В определении написано "независимо", то есть вообще никак. S>>Но в COM приходится обращаться к полиморфным функциям и ты это считаешь независимым G>Наблюдаемое поведение не зависит от конкретного типа.
Зависит от конкретной сущности по указателю.
S>>Берем C++ и два указателя на IUnknown*. Они указывают на один объект? G>Если не совпадают, то нет.
Не угадал. Объект один, указатели разные. Вот когда ты у каждого спросишь QI(IID_IUnknown), то они вернут равные указатели (возможно). Но это опрос состояний сущностей, скрывающимися за указателями. COM identity завязана на состояния и поведение, хочешь ты этого или нет.
G>>>Вообще бывают разные объекты, даже если ты их не умеешь различать (то есть у них нет identity). S>>Слушай, если уж value-типы с identity ты назвал не ООП, то объекты без identity-то, уж наверняка не ООП? Или как? G>Да, требование ООП чтобы у разных объектов были разные identity. Про разные объекты см выше.
А где смотреть про объекты без identity?
S>>>>Что бы получить результат QueryInterface(IUnknown), нужно воспользоваться состоянием и поведением, притом полиморфным. G>>>Каким состоянием? Каким поведением? S>>QI это полиморфная функция. взять результат она может только обращаясь к состоянию. Обеспечить детерминированность она может только обращаясь к состоянию. Или ты знаешь другие варианты? G>Реализация не важна (ты же по сути не знаешь что внутри делает object.ReferenceEquals), важно наблюдаемое снаружи поведение, так во оно в случае QueryInterface(IUnknown) совпадает у всех COM объектов.
О, ну тогда ты же не знаешь что внутри делает MyIdEquals, главное наблюдаемое снаружи Подаешь две ссылки, он отвечает, да или нет.
G>>>Типы — поведение (или состояние, если рассматривать как ссылку на VMT). в COM QueryInterface имеет одни и те же правила работы, независимо то типа. S>>И что? Разве это где-то упомянуто в определении идентити, а я не заметил? G>Типы — поведение (или состояние, если рассматривать как ссылку на VMT\type), ты именно их используешь в своем коде/
Они же используются при QI
G>>>В ECMA это не нужно, там уже можно ссылки сравнивать. Хотя твои размышления натолкнули на мысль что f таки должна быть обратима. Надо более точно сформулировать. S>>Про обратимость f я тебе уже свои размышления показывал. Они привели к противоречию существования такой обратимой f. G>Я еще не сформулировал в каком смысле нужна обратимость.
я знаю обратимость только в одном смысле
G>>>Еще раз: такое поведение у любого объекта. Это особенность самого COM. как сравнение ссылок в CLR. S>>Ну и что? MyIdEquals определяет identity для любого объекта. Это особенность MyIdEquals. G>Нет, внутрь MyIdEquals заложено знание о конкретных классах, в отличие от QueryInterface.
В QI заложено знание о конкретной реализации IUnknown грани.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>>>1)Ты явно используешь поведение, когда сравниваешь строки. S>>>>Не беда G>>>Но это противоречит определению. S>>QueryInterface тоже G>Не-а. G>http://www.daimi.au.dk/~datpete/COT/COM_SPEC/pdf/com_spec.pdf G>Пункт 3.3.1.1
Погоди, ты мне говорил что именно определение идентити ООП запрещает опираться на поведение и состояние. Спека COM официально одобрила использование поведения и состояния для вычисления ID. Это противоречит твоей трактовке идентити ООП.
Короче, или можно использовать состояние, тогда можно сравнивать строки в MyIdEquals. Или нельзя, тогда QI нарушает это правило. Твой выбор?
S>>Я утверждаю что это не ООП инструмент. G>Утверждай дальше, но это не так. Reflecton нигде не противоречит OOP. G>Даже Алан Кей, создатель ООП и языка SmallTalk включил туда reflection. G>Можешь найти хоть одно авторитетное мнение, совпадающее с твоим? http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/rop.html
Здесь ROP считают отдельной парадигмой. Это подтверждает, что оно явно высовывается из рамок OOP.
S>>>>Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду. G>>>Неважно, скажи как отработает в данном коде. S>>В идеале она посчитает что объекты мутабельны и вернет false. G>Отлично, то есть чтобы MyIdentityEquals возвращало true требуется "глубокая" immutability. Это будет не ооп.
В чем это будет не ООП? По каким признакам?
G>>>>>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП. S>>>>Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП G>>>нет, иммутабельная строка не заставляет быть иммутабельными все объекты, а твоя функция IsStructuralEquals будет работать только есть объекты состоят из иммутабельных объектов. Это будет не ООП. S>>На каком основании? Где написано что иммутабельный объект не объект? G>Нигде, но на глубокой иммутабельности у тебя не получится ООП.
Т.е. потому что ты так решил?
Что будет если у меня будут не только immutable объекты?
S>>Причем тут это? QI использует состояние. G>Не использует.
class MyIDispatchFace : public IDispatch
{
public:
IUnknown* QI(IID iid)
{
case IID_IUnknown:
...
}
};
Добавь плиз набросок реализации для случая когда грань IDispatch распологается отдельно от грани IUnknown. А я посмотрю, откуда ты материализуешь результат для QI.
Здравствуйте, samius, Вы писали:
G>>http://www.daimi.au.dk/~datpete/COT/COM_SPEC/pdf/com_spec.pdf G>>Пункт 3.3.1.1 S>Погоди, ты мне говорил что именно определение идентити ООП запрещает опираться на поведение и состояние. Спека COM официально одобрила использование поведения и состояния для вычисления ID. Это противоречит твоей трактовке идентити ООП.
Где ты там состояние увидел?
S>>>Я утверждаю что это не ООП инструмент. G>>Утверждай дальше, но это не так. Reflecton нигде не противоречит OOP. G>>Даже Алан Кей, создатель ООП и языка SmallTalk включил туда reflection. G>>Можешь найти хоть одно авторитетное мнение, совпадающее с твоим? S>http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/sobel/rop.html S>Здесь ROP считают отдельной парадигмой. Это подтверждает, что оно явно высовывается из рамок OOP.
Тем не менее она не противоречит ООП, также как immutable string не противоречит.
А вот если все будет immutable, тогда совсем друга система получится.
S>>>>>Функция не настолько тупа что бы верить атрибуту [Immutable]. Возможно она шуршит по IL коду. G>>>>Неважно, скажи как отработает в данном коде. S>>>В идеале она посчитает что объекты мутабельны и вернет false. G>>Отлично, то есть чтобы MyIdentityEquals возвращало true требуется "глубокая" immutability. Это будет не ооп. S>В чем это будет не ООП? По каким признакам?
По формальным может быть даже получится ООП. Но по сути превратится в ФП.
G>>>>>>А вот кстати использование только immutable объектов в программе скорее всего выходит за рамки ООП. S>>>>>Тогда, скорее всего, любая программа, использующая иммутабельную строку, выходит за рамки ООП G>>>>нет, иммутабельная строка не заставляет быть иммутабельными все объекты, а твоя функция IsStructuralEquals будет работать только есть объекты состоят из иммутабельных объектов. Это будет не ООП. S>>>На каком основании? Где написано что иммутабельный объект не объект? G>>Нигде, но на глубокой иммутабельности у тебя не получится ООП. S>Т.е. потому что ты так решил? S>Что будет если у меня будут не только immutable объекты?
Тогда у тебя MyEquals будет практически бесполезной функцией.
S>>>Причем тут это? QI использует состояние. G>>Не использует.
S>
S>Добавь плиз набросок реализации для случая когда грань IDispatch распологается отдельно от грани IUnknown. А я посмотрю, откуда ты материализуешь результат для QI.
Такого быть не может, IDispatch наследуется от IUnknown.
Так что с точки зрения C++ код всегда будет
class MyIDispatchFace : public IDispatch
{
public:
IUnknown* QI(IID iid)
{
case IID_IUnknown:
return this;
...
}
};
G>>>Фаулер опирается на заблуждение ANS>>Это не заблуждение, это примитивизация. G>Нет, это именно заблужение. До буча с мейером никто не говорил что объекты — данные+методы, обязательно вместе. Откуда это они взяли — неизвестно.
Это rule of thumb. Ситуация, когда состояние общее и шарится между разными категориями мутаторов может и имеет право на жизнь, но не в случае anemic.
G>Даже design patterns описывает классы и объекты, большинство из которых не имеет данных\состояния.
Здравствуйте, Sinclair, Вы писали:
ANS>>Извини, я до этого места статью был не дочитал Я остановился на втором абзаце. И сходу вопрос, почему "Transaction Script" это "чисто процедурное овно"? S>А ты нажми на ссылку "Transaction Script", которую он приводит.
Здравствуйте, gandjustas, Вы писали:
G>Яж говорю, фаулер устарел. Он до сих пор "продает" то что было актуально 10 лет назад, а сейчас уже стало нормальным и перекочевало из разряда новшеств в разряд инструментов.
"Устарел" != "в корне не прав". btw, когда выложили архивы "Smalltalk Report" — я был разочарован тем, что прогресс за более чем за 10 лет никуда не сдвинулся. Что за последние 5 лет что-то принципиально изменилось? Сомневаюсь.
Здесь нет иррациональных числел Sqrt это функция которая всегда возвращает рациональное число Более того, любая другая функция тоже вернет рациональное число. Более того, любое число, которое может быть представлено в конкретном компьютере, будет рациональным.
Необходимое и достаточное условие для представления иррациональных чисел это возможность представить бесконечнечную непериодическую дробь.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Яж говорю, фаулер устарел. Он до сих пор "продает" то что было актуально 10 лет назад, а сейчас уже стало нормальным и перекочевало из разряда новшеств в разряд инструментов.
ANS>"Устарел" != "в корне не прав".
Неправ в том что продолжает популяризировать старые идеи. Большинство из которых потеряли актуальность.
И сказали считать их идентичными. Т.е. два разных значения, в разных location, они велели считать идентичными. Ничего не смущает? Я о том и говорю, что именно идентичность говорит что считать идентичным чему.
