Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>Это тафтология, потому как именно id определяет, один и тот же объект или нет. G>>Нет, объекты априори бывают разные. А id позволяет это определять в программе. В определении так и написано: "id позволяет различать разные объекты", не написано что "id определяет объект". S>ECMA335 определяет идентичность и тем самым устанавливает, где один объект, а где другой. Другая идентичность введет другое отношение. Почему ты ожидаешь от другой идентичности что она будет оперировать "объектами по ECMA335"? ECMA335 объект != объект по любой другой идентичности, отличающейся от ECMA335. Есть какие-то проблемы с пониманием этого?
Идентичность не есть объект, это свойство объекта, читай определение. То есть объект в широком смысле может существовать и без идентичности.
Например две строки в БД без ключей. Если они совпадают, то это никак не различишь их. Но тем не менее это разные объекты.
Вот как раз ооп говорит что разные объекты должны быть различимы с помощью id.
Смотри:
var a = new object();
var b = new object();
var c = a;
a и b — разные объекты, их identity должны различаться. a и c — один и тот же объект, соответственно id, полученное из a и c будет совпадать.
Если ты id определить как структурную эквивалентность — это не будет выполняться.
G>>Нет, исходя из интерфейса выше функцию дирихле написать легко. И даже алгебру таких объектов посторить легко. Можно даже написать функцию Sqrt, которая вернет правильный результат. А вот логарифм, тригонометрия — уже не получится. Но ведь на функцию дирихле оно никак не повлияет. S>Функция Дирихле изоморфна задаче определения иррациональности числа. Ты предлагаешь выпихнуть эту задачу из функции. Ну да ладно, задача-то осталась не решена, хоть функция и будет написана. Я так же могу написать функцию, коллапсирующую вселенную. Давай с этим завязывать.
Это она в математике изоморфна, а в компьютере приходится учитывать специфику. Почитай кнута, третий том кажись, про арифметику в компьютере.
G>>>>1)Придумать как обращаться с ними в программе (ссылки, которые при этом нельзя сравнить) S>>>Ссылки будут теми же самыми, сравнивать их можно будет, но делать выводы об идентичности отличной от ECMA-335 по этому сравнению будет очевидно нельзя. G>>Тогда их сравнивать бессмысленно и можно просто запретить операцию. S>Зачем запрещать? Идентичность по ECMA останется. Вдруг, запретив ReferenceEquals, мы не сможем поднять рантайм?
Ты же предлагаешь написать что-то, что сможет заменить referenceequals.
G>>>>4)Придумать как сравнивать identity S>>>с помощью функции MyIdEquals. G>>Так её надо написать и она должна быть вычислимой. S>Если бы ты согласился с тем что алтернативная идентичность задает альтернативное отношение идентичности/эквивалентности объектов, то уже сам бы написал.
Нету альтернативной идентичности, идентичность задается определением. Могут быть разные реализации. Но ты пока не привел ни одной, которая никак не противоречит определению.
G>>>>5)Доказать что между значением id(object) и ссылкой нет взаимно однозначного соответствия. S>>>Для этого ведь достаточно будет показать что результаты MyIdEquals будут отличаться от ReferenceEquals G>>Нет, не достаточно.
G>>Если у тебя MyIdEquals(a,b) != ReferenceEquals(a,b), G>>то вполне возможно существует f, такая что MyIdEquals(a,b) == MyIdEquals(f(a),f(b)) == ReferenceEquals(f(a),f(b))
G>>На примере COM, там в качестве f будет QueryInterface(IUnknown) S>Ты требуешь чего-то непонятного. Даже при существовании такой функции f (забудем пока про взаимную однозначность) MyIdEquals будет отличаться от ReferenceEquals S>MyIdEquals(a,b) == MyIdEquals(f(a),f(b)) == ReferenceEquals(f(a),f(b)) != ReferenceEquals(a, b)
S>А теперь по поводу взаимной однозначности f. Если она взаимно однозначна, то существует обратная ей взаимно однозначная f' такая что f'(f(a))==a и f'(f(b))==b. Из равенства ссылок f(a)==f(b) будет следовать a==b....
Да, взаимной однозначности этой функции не нужно, это я сдуру написал.
Посмотри как оно работает в COM. Там ссылки на объект могут не совпадать если запрашивать разные интерфейсы, но если запрашивать IUnknown то полученные ссылки будут совпадать.
G>>>>Ты так и не смог сказать что такое логическая идентичность, оно у тебя больше похоже на эквивалентность, которая в общем случае идентичностью не является. S>>>Вообще говоря, хорошая идентичность будет эквивалентностью. G>>Вообще говоря любая Даже без ООП
S>Давай тогда разберемся. чем идентичность отличается от отношения эквивалентности кроме требований возможности отправки сообщения по ссылке, сохранения идентичности при смене состояния?
Идентичность такое отношение эквивалентности, при котором объект эквивалентен сам себе и не эквивалентен, независимо от состояния и поведения.
S>Что может мою идентичность сделать неидентичностью в общем смысле? Что ее отличает от идентичности ECMA — я догадываюсь
То что твоя идентичность будет зависеть от состояния и\или поведения.
G>>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи. S>По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что.
Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>>>Это противоречит определению так как ты на состояние будешь ориентироваться. S>>>Определение не запрещает ориентироваться. Оно запрещает id изменяться вместе с состоянием объекта.
G>>Ну так оно у тебя будет меняться. Даже readonly можно поменять с помощью рефлексии, все еще оставаясь в рамках CLR. S>Но не в рамках OOP
Причем тут ООП? В ООП есть неизменяемые поля? readonly — не более чем особенность компилятора.
G>>>>Это получится как раз определение эквивалентности, но не идентичности. S>>>И эквивалентности и идентичности. G>>Нет, не идентичности. S>Я читаю определени идентичности так: независит от состояния == сохраняется при изменении состояния.
Да, причем при любом изменении, доступном в рамках системы. Конкретно в рамках СLR.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, artelk, Вы писали:
A>>>Например, назначать коллекции стратегию сравнивания. G>>Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item) S>По назначенному компареру
Еще раз: нет возможности переопределить операцию сравнения никак, ни компарер, ни equals, вообще никак.
A>>>А вообще, вопрос был не в том, с какими проблемами мы можем столкнуться в текущем проекте, если с завтрашнего дня внезапно появится запрет на вызов ReferenceEquals и всего, что его использует. G>>Как минимум BCL не соберется\перестанет работать. Ты кстати скорее всего можешь сымитировать ситуацию через profile api, подменив вызов RefenceEquals, если он не intrsink какойнить. S>Нет цели заставить работать BCL, нет нужды подменять вызов ReferenceEquals. Мы просто показываем, что остаемся в рамках OOP, ослабив идентичность ECMA~location. Других целей нет.
Ну показывай. Тебе это не удается.
G>>>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm A>>>Хорошая ссылка. G>>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же. S>Все три допускают идентичность более слабую, чем ECMA.
Приведи пример. Пока это не удалось никому.
A>>>Определение через locations — слишком узко. G>>Для чего? Практика показывает что для CLR самое то. Ты не можешь расширить это определение (то есть получить идентичность без равенства ссылок) оставаясь в рамках ECMA-335. S>Отказываясь от идентичности ECMA-335 мы уже выходим за его рамки просто по определению. Раз выходим — нет нужды в них обратно лезть.
То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок?
G>>Источник твоего "вдохновения" в этом случае — РСУБД, которая не является ОО-системой если что S>Ну и что? Я не понимаю, чего ты боишься? Что вдруг окажется что альтернативная идентичность может иметь место? Тебя ведь не заставляют ее использовать вместо ECMA?
Я ничего не боюсь, ты просто приводи адекватные примеры. Нас интересует идентичность в ОО системах, например реляционная алгебра не требует идентичности, там определяй или нет — твое дело.
Здравствуйте, gandjustas, Вы писали:
G>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок?
В рамках определения понятия "идентичность", данного в ECMA-335 — конечно невозможно.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок? A>В рамках определения понятия "идентичность", данного в ECMA-335 — конечно невозможно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
G>>>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок? A>>В рамках определения понятия "идентичность", данного в ECMA-335 — конечно невозможно.
G>Нет в рамках определения по ссылке http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm, но чтобы работало в CLR. G>Ты же именно это пытаешься доказать уже на протяжении кучи постов.
Ага, а критерием, для выяснения того, что мне это удалось или нет, будет выступать то, на сколько оно удовлетворяет определениям из ECMA-335...
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
G>>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm A>>Хорошая ссылка. G>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же.
Кстати, а чем ты руководствуешься, утверждая, что эти определения верны, а, например, приведенные в википедии — нет; что выступает в качестве критерия их верности?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>ECMA335 определяет идентичность и тем самым устанавливает, где один объект, а где другой. Другая идентичность введет другое отношение. Почему ты ожидаешь от другой идентичности что она будет оперировать "объектами по ECMA335"? ECMA335 объект != объект по любой другой идентичности, отличающейся от ECMA335. Есть какие-то проблемы с пониманием этого?
G>Идентичность не есть объект, это свойство объекта, читай определение. То есть объект в широком смысле может существовать и без идентичности. G>Например две строки в БД без ключей. Если они совпадают, то это никак не различишь их. Но тем не менее это разные объекты. G>Вот как раз ооп говорит что разные объекты должны быть различимы с помощью id.
G>Смотри:
G>
G>var a = new object();
G>var b = new object();
G>var c = a;
G>
G>a и b — разные объекты, их identity должны различаться. a и c — один и тот же объект, соответственно id, полученное из a и c будет совпадать. G>Если ты id определить как структурную эквивалентность — это не будет выполняться.
Хм, именно так, через структурную эквивалентность в ECMA определили identity для value type И сказали считать их идентичными. Т.е. два разных значения, в разных location, они велели считать идентичными. Ничего не смущает? Я о том и говорю, что именно идентичность говорит что считать идентичным чему.
S>>Функция Дирихле изоморфна задаче определения иррациональности числа. Ты предлагаешь выпихнуть эту задачу из функции. Ну да ладно, задача-то осталась не решена, хоть функция и будет написана. Я так же могу написать функцию, коллапсирующую вселенную. Давай с этим завязывать. G>Это она в математике изоморфна, а в компьютере приходится учитывать специфику. Почитай кнута, третий том кажись, про арифметику в компьютере.
Я не представляю, о какой специфике ты говоришь. На бумаге тоже пока никто не записал иррационального числа. До сих пор только обозначали их.
G>>>Тогда их сравнивать бессмысленно и можно просто запретить операцию. S>>Зачем запрещать? Идентичность по ECMA останется. Вдруг, запретив ReferenceEquals, мы не сможем поднять рантайм? G>Ты же предлагаешь написать что-то, что сможет заменить referenceequals.
Нет, не предлагал его заменять.
S>>Если бы ты согласился с тем что алтернативная идентичность задает альтернативное отношение идентичности/эквивалентности объектов, то уже сам бы написал. G>Нету альтернативной идентичности, идентичность задается определением. Могут быть разные реализации. Но ты пока не привел ни одной, которая никак не противоречит определению.
Синклер приводил.
G>Посмотри как оно работает в COM. Там ссылки на объект могут не совпадать если запрашивать разные интерфейсы, но если запрашивать IUnknown то полученные ссылки будут совпадать.
Ну и незачем на него смотреть. COM явно выпадает из определения идентичности в OOP если не запрашивать IUnknown, хотя бы потому как нарушена рефлексивность. Если запрашивать IUnknown и только лишь его, то COM становится ничем не интереснее обычного объекта при условии корректной реализации.
S>>Давай тогда разберемся. чем идентичность отличается от отношения эквивалентности кроме требований возможности отправки сообщения по ссылке, сохранения идентичности при смене состояния? G>Идентичность такое отношение эквивалентности, при котором объект эквивалентен сам себе и не эквивалентен, независимо от состояния и поведения.
полагаю, что "не" лишняя.
Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность.
S>>Что может мою идентичность сделать неидентичностью в общем смысле? Что ее отличает от идентичности ECMA — я догадываюсь G>То что твоя идентичность будет зависеть от состояния и\или поведения.
Не будет.
G>>>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи. S>>По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что. G>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
А я тебе говорю, что
1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение.
2) существование отображения — это слишком сильное требование. Допустим, по моей identity две равных (ordered) строки будут идентичны, в отличии от ECMA-335. Ты мне создаешь функцию, которая будет всегда возвращать интернированную строку, и получается что ReferenceEquals(f(a), f(b)) == true. Хотя по определению ECMA эти строки будут разными объектами, т.к. ReferenceEquals(a, b) == false. И что ты мне хочешь доказать существованием такого отображения? Что две identity эквивалентны? Нет, они не эквивалентны.
Забудь про отображение f. Ничего оно никому не дает.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>>>Это противоречит определению так как ты на состояние будешь ориентироваться. S>>>>Определение не запрещает ориентироваться. Оно запрещает id изменяться вместе с состоянием объекта.
G>>>Ну так оно у тебя будет меняться. Даже readonly можно поменять с помощью рефлексии, все еще оставаясь в рамках CLR. S>>Но не в рамках OOP G>Причем тут ООП? В ООП есть неизменяемые поля? readonly — не более чем особенность компилятора.
readonly непричем. Причем тут то, что рефлексия позволяет обходить инкапсуляцию данных. Это не ООП инструмент.
S>>Я читаю определени идентичности так: независит от состояния == сохраняется при изменении состояния. G>Да, причем при любом изменении, доступном в рамках системы. Конкретно в рамках СLR.
Конкретно в рамках CLR идентичность при изменении состояния не сохраняется у value типов. Не нужен даже рефлекшн
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item) S>>По назначенному компареру G>Еще раз: нет возможности переопределить операцию сравнения никак, ни компарер, ни equals, вообще никак.
Остается задвинуть на эту досадную коллекцию. Никто не обещал совместимость альтернативной идентичности со всем написанным кодом.
S>>Нет цели заставить работать BCL, нет нужды подменять вызов ReferenceEquals. Мы просто показываем, что остаемся в рамках OOP, ослабив идентичность ECMA~location. Других целей нет. G>Ну показывай. Тебе это не удается.
G>>>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же. S>>Все три допускают идентичность более слабую, чем ECMA. G>Приведи пример. Пока это не удалось никому.
Я думаю, что никто не пытался
S>>Отказываясь от идентичности ECMA-335 мы уже выходим за его рамки просто по определению. Раз выходим — нет нужды в них обратно лезть. G>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок?
Я не собирался определять идентичность в CLR. Я собирался показать отношение, удовлетворяющее идентичности ООП и отличное от идентичности ECMA-335. Из CLR ты можешь на него смотреть как на еще одно отношение эквивалентности.
S>>Ну и что? Я не понимаю, чего ты боишься? Что вдруг окажется что альтернативная идентичность может иметь место? Тебя ведь не заставляют ее использовать вместо ECMA? G>Я ничего не боюсь, ты просто приводи адекватные примеры. Нас интересует идентичность в ОО системах, например реляционная алгебра не требует идентичности, там определяй или нет — твое дело.
Сначала надо отвоевать позиции по определениям идентичностей. А после этого придет разочарование, т.к. ввести идентичность будет слишком тривиально, и практически нафиг не нужно.
Но вот, незадача, еще один фронт открылся — рефлексионный...
Здравствуйте, samius, Вы писали:
S>Там, где ты выделил жирным, ты описал свойство identity через понятие одинаковых и разных объектов. Я пишу что наоборот, identity определяет где разные, а где одинаковые (same) объекты.
Теория требует, чтобы identity и, э-м-м, "самоэквивалентность" объекта были одним и тем же. Не задавая какого-то конкретного "направления" эквивалентности.
Проводим простой эксперимент: определяем функцию ID(obj) == 0.
Эта функция вводит вполне нормальное с точки зрения математики отношение эквивалентности. Наша идентити успешно определила все объекты, как одинаковые. Подходит ли она под определение identity из OOP или всё-таки нет?
Если не подходит, то почему?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
A>artelk> Приведи пример задачи, которую нельзя решить без использования object.ReferenceEquals. A>gandjustas> Хорошо, задача: нужно реализовать object.ReferenceEquals с текущим его поведением. A>
A>Когда может такое случиться, что мы не сможем предоставить коллекции свой equals (вычисляемый как функция состояния объекта) не выходя за рамки ООП парадигмы?
Да сразу же, как начнём писать.
public class Crash
{
public int A { get; set; }
public override bool Equals(object o) {??? };
}
var a = new Crash(); a.A = 1;
var b = new Crash(); b.A = 2;
var l = new List<A>();
l.Add(a); l.Add(b);
a.A = 2;
l.Remove(b);
a.A = 1;
Assert(l.IndexOf(a) >= 0);
Приведите, пожалуйста, свою перегрузку метода Equals, не использующую сравнение ссылок. Задача — в том, чтобы ассерт выполнился.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, artelk, Вы писали:
G>>>>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок? A>>>В рамках определения понятия "идентичность", данного в ECMA-335 — конечно невозможно.
G>>Нет в рамках определения по ссылке http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm, но чтобы работало в CLR. G>>Ты же именно это пытаешься доказать уже на протяжении кучи постов.
A>Ага, а критерием, для выяснения того, что мне это удалось или нет, будет выступать то, на сколько оно удовлетворяет определениям из ECMA-335...
Нет. Надо чтобы удовлетворяло определениям по ссылке, но работало в CLR.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, artelk, Вы писали:
G>>>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm A>>>Хорошая ссылка. G>>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же. A>Кстати, а чем ты руководствуешься, утверждая, что эти определения верны, а, например, приведенные в википедии — нет; что выступает в качестве критерия их верности?
Википедии вообще не доверяю, там шлака много. Ты же сам приводил очень противоречивые цитаты оттуда.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, artelk, Вы писали:
G>>>>>http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?OID/index.htm A>>>>Хорошая ссылка. G>>>Конечно, прочитай внимательно все три определения. Все три верны и отражают разные аспекты одного и того же. A>>Кстати, а чем ты руководствуешься, утверждая, что эти определения верны, а, например, приведенные в википедии — нет; что выступает в качестве критерия их верности?
G>Википедии вообще не доверяю, там шлака много. Ты же сам приводил очень противоречивые цитаты оттуда.
А не, это не ты приводил. Ну прочитай тему внимательно, там много чего есть.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>Хм, именно так, через структурную эквивалентность в ECMA определили identity для value type И сказали считать их идентичными. Т.е. два разных значения, в разных location, они велели считать идентичными. Ничего не смущает? Я о том и говорю, что именно идентичность говорит что считать идентичным чему.
Не смущает. Value-type находится за пределами ООП, там это совершенно нормально.
Мы ведь все еще про ООП говорим, не так ли?
S>>>Функция Дирихле изоморфна задаче определения иррациональности числа. Ты предлагаешь выпихнуть эту задачу из функции. Ну да ладно, задача-то осталась не решена, хоть функция и будет написана. Я так же могу написать функцию, коллапсирующую вселенную. Давай с этим завязывать. G>>Это она в математике изоморфна, а в компьютере приходится учитывать специфику. Почитай кнута, третий том кажись, про арифметику в компьютере. S>Я не представляю, о какой специфике ты говоришь. На бумаге тоже пока никто не записал иррационального числа. До сих пор только обозначали их.
Нет, на бумаге мы оперируем символьными вычислениями, а в компьютере — значениями.
G>>>>Тогда их сравнивать бессмысленно и можно просто запретить операцию. S>>>Зачем запрещать? Идентичность по ECMA останется. Вдруг, запретив ReferenceEquals, мы не сможем поднять рантайм? G>>Ты же предлагаешь написать что-то, что сможет заменить referenceequals. S>Нет, не предлагал его заменять.
Идентичность для reference-типов в CLR реализуется referenceequals, ты хотел свою идентичность написать, то есть по сути заменить этот referenceequals.
S>>>Если бы ты согласился с тем что алтернативная идентичность задает альтернативное отношение идентичности/эквивалентности объектов, то уже сам бы написал. G>>Нету альтернативной идентичности, идентичность задается определением. Могут быть разные реализации. Но ты пока не привел ни одной, которая никак не противоречит определению. S>Синклер приводил.
Ага, она очень легко сводится в сравнению ссылок.
G>>Посмотри как оно работает в COM. Там ссылки на объект могут не совпадать если запрашивать разные интерфейсы, но если запрашивать IUnknown то полученные ссылки будут совпадать. S>Ну и незачем на него смотреть. COM явно выпадает из определения идентичности в OOP если не запрашивать IUnknown, хотя бы потому как нарушена рефлексивность. Если запрашивать IUnknown и только лишь его, то COM становится ничем не интереснее обычного объекта при условии корректной реализации.
Ни разу не выпадает. У объектов есть identity, им можно отправлять сообщения. Там и наследование и полиморфизм тоже есть.
То есть формально com соответствует ООП.
S>>>Давай тогда разберемся. чем идентичность отличается от отношения эквивалентности кроме требований возможности отправки сообщения по ссылке, сохранения идентичности при смене состояния? G>>Идентичность такое отношение эквивалентности, при котором объект эквивалентен сам себе и не эквивалентен, независимо от состояния и поведения. S>полагаю, что "не" лишняя.
Нет, не написал что не эквивалентен другим объектам.
S>Вот как раз ECMA-335 8.2.5.1 пункт 2 задает идентичность для value types с нарушением двух пунктов. Значение эквивалентно самому себе и всем другим с подобными bit sequences. И состояние может нарушить эту идентичность.
Но value-types — не ооп. Там свойство идентичности, которое говорит о том что для идентичных объектов любое изменение в одном отражается на другом, не выполняется.
S>>>Что может мою идентичность сделать неидентичностью в общем смысле? Что ее отличает от идентичности ECMA — я догадываюсь G>>То что твоя идентичность будет зависеть от состояния и\или поведения. S>Не будет.
Ты же сам говоришь что она будет реализована через операцию сравнения полей (состояния).
G>>>>Я как-то с самого начала не запутался. Хотя надо было сразу прочитать Ecma-335, а не пытаться тебе доказывать очевидные вещи. S>>>По-моему ты все еще пытаешься найти опровержение другим идентичностям, оперируюя идентичностью ECMA-335. Залез в скафандр ECMA-335 и говоришь что другие скафандры фуфло, потому как в них нельзя влезть, не снимая ECMA-335. Извини, если что. G>>Ну я тебе говорю, предложи другую систему, где identity будет не ссылкой и не будет существовать отображения f которая сделает ссылки равными для объектов с совпадающим identity.
S>А я тебе говорю, что S>1) identity это не ссылка даже по ECMA-335. По ECMA identity это бинарное отношение.
Бинарное отношение в каком множестве? Видимо "ссылок".
S>2) существование отображения — это слишком сильное требование. Допустим, по моей identity две равных (ordered) строки будут идентичны, в отличии от ECMA-335. Ты мне создаешь функцию, которая будет всегда возвращать интернированную строку, и получается что ReferenceEquals(f(a), f(b)) == true. Хотя по определению ECMA эти строки будут разными объектами, т.к. ReferenceEquals(a, b) == false. И что ты мне хочешь доказать существованием такого отображения? Что две identity эквивалентны? Нет, они не эквивалентны.
Нет ты опять пытаешься опираться на поведение, определяя идентичность через некоторые свойства объекта. Для начала построй идентичность, которая будет для любого типа работать, а потом будем искать f. Если ты найдешь f для какого типа идентичность не появится
S>Забудь про отображение f. Ничего оно никому не дает.
В COM дает, ты споришь с фактами.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>>>Коллекция тоже не тобой написана. Счиатй что у тебя изначально нет возможности переопределит операцию сравнения. Как будет выполняться операция Collection.Remove(item) S>>>По назначенному компареру G>>Еще раз: нет возможности переопределить операцию сравнения никак, ни компарер, ни equals, вообще никак. S>Остается задвинуть на эту досадную коллекцию. Никто не обещал совместимость альтернативной идентичности со всем написанным кодом.
Тем не менее коллекция есть, объект есть, сделай так чтобы Collectio.Remove(item) работало. Ведь в CLR оно работает.
Будем считать что у тебя есть возможность сделать свою идентичность для CLR, как ты её определишь? Естественно ты тип item заранее не знаешь.
S>>>Отказываясь от идентичности ECMA-335 мы уже выходим за его рамки просто по определению. Раз выходим — нет нужды в них обратно лезть. G>>То есть ты согласен, что в clr невозможно определить идентичность не сравнением ссылок? S>Я не собирался определять идентичность в CLR. Я собирался показать отношение, удовлетворяющее идентичности ООП и отличное от идентичности ECMA-335. Из CLR ты можешь на него смотреть как на еще одно отношение эквивалентности.
Оно должно быть отношением идентичности в CLR или другой системе, которую ты придумаешь. При этом не должно существовать функции f, позволяющей свести твое отношение идентичности к сравнению "ссылок".
Такой пример уже есть. COM — формально ООП, для идентичных объектов могут ссылки не совпадать, но при QureyInterface(IUnknown) совпадают.
S>Но вот, незадача, еще один фронт открылся — рефлексионный...
Никаких фронтов. Сравнение неизменяемого состояния опирается как на само состояние (значения), так и на поведение (неизменяемость). Такая эквивалентность вдвойне неправильна а CLR позволяет быстро это доказать.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>Там, где ты выделил жирным, ты описал свойство identity через понятие одинаковых и разных объектов. Я пишу что наоборот, identity определяет где разные, а где одинаковые (same) объекты. S>Теория требует, чтобы identity и, э-м-м, "самоэквивалентность" объекта были одним и тем же. Не задавая какого-то конкретного "направления" эквивалентности.
Не понял, к чему это. Под самоэквивалентностью подразумевается рефлексивность? Если да, то оно требуется отношением эквивалентности. Identity должна быть эквивалентностью. Это напрямую не требуется, но без этого все криво. Или самоэквивалентность это что-то другое?
S>Проводим простой эксперимент: определяем функцию ID(obj) == 0.
Очень интересный эксперимент
Правда,
S>Эта функция вводит вполне нормальное с точки зрения математики отношение эквивалентности. Наша идентити успешно определила все объекты, как одинаковые. Подходит ли она под определение identity из OOP или всё-таки нет?
Да, подходит. Формально подходит. Она задает идентичность таким образом, что у нас в системе существует не более одного объекта. И даже эта идентичность позволяет отличать этот объект от всех остальных, как и написано в определении. Проблема лишь в том, что остальных не будет, т.к. объектов не более одного.
S>Если не подходит, то почему?
Подходит. Бредово, но согласно моему пониманию идентичности, именно идентичность указывает где same объекты, а где нет. И identity из ECMA именно так и поступает в отношении value типов.
Да, value не объекты. Но и идентичность в ECMA задана не для объектов а для значений. И в отношении value значений она однозначно указывает что два значения надо считать идентичными при совпадении bit sequences.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, artelk, Вы писали:
S>
S>public class Crash
S>{
S> public int A { get; set; }
S> public override bool Equals(object o) {??? };
S>}
S>var a = new Crash(); a.A = 1;
S>var b = new Crash(); b.A = 2;
S>var l = new List<A>();
S>l.Add(a); l.Add(b);
S>a.A = 2;
S>l.Remove(b);
S>a.A = 1;
S>Assert(l.IndexOf(a) >= 0);
S>
S>Приведите, пожалуйста, свою перегрузку метода Equals, не использующую сравнение ссылок. Задача — в том, чтобы ассерт выполнился.
"Не использующую сравнение ссылок" — это слишком жестоко. artelk говорил о том что идентичность ECMA слишком сильная и что ее можно ослабить. Это не значит что нужно совсем отказаться от сравнения ссылок. Ослаблять идентичность ECMA опять-таки можно не где-попало. И этот пример это подтверждает.
Даже без ООП
И сказали считать их идентичными. Т.е. два разных значения, в разных location, они велели считать идентичными. Ничего не смущает? Я о том и говорю, что именно идентичность говорит что считать идентичным чему.
