G> string y = "2";
G> string z = y;
G> string y1 = y;
G> string z1 = z;
G> Console.WriteLine(Object.ReferenceEquals(z, y));
G> y += "1";
G> z += "1";
G> Console.WriteLine(Object.ReferenceEquals(z, y));
G> Console.WriteLine(Object.ReferenceEquals(z1, y1));//Ну ты понял ;)
G>
твое "ну, понял" справедливо только при следующих утверждениях:
1) y1 и y (а также z1 и z) — это один и тот же объект
2) y до изменения и y после (а также z) — это разные объекты
на основании чего ты сделал все эти выводы?
на основе внутреннего знания как устроены строки в .net?
тогда ты нарушил принцип инкапсуляции, и это уже никакого отношения к ООП не имеет.
G>> string y = "2";
G>> string z = y;
G>> string y1 = y;
G>> string z1 = z;
G>> Console.WriteLine(Object.ReferenceEquals(z, y));
G>> y += "1";
G>> z += "1";
G>> Console.WriteLine(Object.ReferenceEquals(z, y));
G>> Console.WriteLine(Object.ReferenceEquals(z1, y1));//Ну ты понял ;)
G>>
DG>твое "ну, понял" справедливо только при следующих утверждениях: DG>1) y1 и y (а также z1 и z) — это один и тот же объект
Присваивание ссылок очевидно сохраняет identity.
DG>2) y до изменения и y после (а также z) — это разные объекты
Да, это настолько очевидно что я даже не написал код для проверки
DG>на основании чего ты сделал все эти выводы? DG>на основе внутреннего знания как устроены строки в .net? DG>тогда ты нарушил принцип инкапсуляции, и это уже никакого отношения к ООП не имеет.
Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.
Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.
DG>>>определи, пожалуйста, раз это легко сделать.
S>>Пардон, с наскоку не получилось сравнить структуры побитово.
DG>тогда из этого следует, что Ecma identity не может использоваться как функция идентификации объектов, потому что она нарушает инкапсуляцию объектов.
Для структур identity определяется по другому и оно не является identity в смысле ООП
Здравствуйте, DarkGray, Вы писали:
S>>После изменения значений переменных, ссылки, которые в них хранятся, больше не указывают на один и тот же объект.
DG>как ты узнал, что они больше не ссылаются на один и тот же объект?
ReferenceEquals
DG>через ReferenceEquals? т.е. ты ReferenceEquals используешь и для проверки, что ссылки остались теми же, и для определения идентичности объектов?
Совершенно верно. Identity is implemented on System.Object via the ReferenceEquals method. (ц)
DG>но в определение явно указано, что это две разных функции: функция сравнения ссылок и функция проверки идентичности
Вообще говоря — это разные функции в широком смысле. Но разве что-то мешает определять одну через другую?
S>> Что RefEquals не может выступать в роли критерия идентичности?
DG>конечно, потому что сравнение ссылок, а не сравнение объектов, что и следует из названия
А из ECMA следует что идентичность реализована через сравнение ссылок. И именно это определяет, где один объект, а где другой.
DG>>>определи, пожалуйста, раз это легко сделать.
S>>Пардон, с наскоку не получилось сравнить структуры побитово.
DG>тогда из этого следует, что Ecma identity не может использоваться как функция идентификации объектов,
Я походу пропустил какое-то звено в рассуждениях. Следствие для меня неочевидно.
Не получилось у меня именно сравнение по memcmp структур, содержащих ссылки. Это не значит, что сравнение структур побитово невыполнимо.
DG>потому что она нарушает инкапсуляцию объектов.
А разве есть какая-то связь?
DG>>твое "ну, понял" справедливо только при следующих утверждениях: DG>>1) y1 и y (а также z1 и z) — это один и тот же объект G>Присваивание ссылок очевидно сохраняет identity.
как только появляется слово "очевидно", то это означает, что человек не может объяснить происходящее.
откуда известно, что в данном месте происходит присвоение ссылок, а не что-то другое?
DG>>2) y до изменения и y после (а также z) — это разные объекты G>Да, это настолько очевидно что я даже не написал код для проверки
G>
пока не доказано, что сравнение объектов y и y1 имеет хоть какое-нибудь отношение к сравнению объекта y (до) с y (после).
G>Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.
правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?
G>Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.
является ли операция += полиморфной в C#? и если она такой является, то каким контрактом она при этом обладает?
DG>>как ты узнал, что они больше не ссылаются на один и тот же объект? S>ReferenceEquals
не канает.
referenceequals сравнивает ссылки на объекты, что следует из ее названия
а из различности ссылок не следует, что объекты разные.
DG>>через ReferenceEquals? т.е. ты ReferenceEquals используешь и для проверки, что ссылки остались теми же, и для определения идентичности объектов? S>Совершенно верно. Identity is implemented on System.Object via the ReferenceEquals method. (ц)
откуда следует, что данное identity и ООП-identity — это одно и тоже?
DG>>но в определение явно указано, что это две разных функции: функция сравнения ссылок и функция проверки идентичности S>Вообще говоря — это разные функции в широком смысле. Но разве что-то мешает определять одну через другую?
не мешает, но тогда мы получим вырожденый случай ООП, который к самому ООП имеет малое отношение (примерно такое же, какое точка имеет отношение к кругу)
DG>>потому что она нарушает инкапсуляцию объектов. S>А разве есть какая-то связь?
конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.
и соотственно, если объект не предоставляет функцию для своего побитового сравнения, то это означает, что с точки зрения ООП ты не имеешь права использовать функцию побитивого сравнения для чего либо.
DG>>>как ты узнал, что они больше не ссылаются на один и тот же объект? S>>ReferenceEquals
DG>не канает. DG>referenceequals сравнивает ссылки на объекты, что следует из ее названия DG>а из различности ссылок не следует, что объекты разные.
Следует по Ecma-335 8.2.5.1
DG>>>через ReferenceEquals? т.е. ты ReferenceEquals используешь и для проверки, что ссылки остались теми же, и для определения идентичности объектов? S>>Совершенно верно. Identity is implemented on System.Object via the ReferenceEquals method. (ц)
DG>откуда следует, что данное identity и ООП-identity — это одно и тоже?
Тогда следует заняться более общими вопросами, например, откуда следует что объекты в C# это ООП-объекты.
DG>>>но в определение явно указано, что это две разных функции: функция сравнения ссылок и функция проверки идентичности S>>Вообще говоря — это разные функции в широком смысле. Но разве что-то мешает определять одну через другую?
DG>не мешает, но тогда мы получим вырожденый случай ООП, который к самому ООП имеет малое отношение (примерно такое же, какое точка имеет отношение к кругу)
А это и есть вырожденный случай ООП. Он, например, имеет мало отношения к вырожденному случаю с COM OOP со своей identity. Правда, у них есть много общего. Например, то, что отношение идентичности в них выполняет условия отношения эквивалентности.
DG>>>потому что она нарушает инкапсуляцию объектов. S>>А разве есть какая-то связь?
DG>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.
Оператор (==) по умолчанию для value типов относится ко внешнему контракту?
DG>и соотственно, если объект не предоставляет функцию для своего побитового сравнения, то это означает, что с точки зрения ООП ты не имеешь права использовать функцию побитивого сравнения для чего либо.
Ну а если для побитового сравнения используется возможность рантайма?
S>Она является функцией идентичности по ECMA для ссылочных типов.
если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?
Здравствуйте, DarkGray, Вы писали:
S>>Она является функцией идентичности по ECMA для ссылочных типов.
DG>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?
Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
Здравствуйте, DarkGray, Вы писали:
G>>Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.
DG>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?
Кроме тех случаев, когда работают conversion операторы. Но даже тогда, резултатом присваивания будет присваивание ссылки.
G>>Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.
DG>является ли операция += полиморфной в C#? и если она такой является, то каким контрактом она при этом обладает?
Полиморфным является (+), а (+=) это лишь сахар, результатом которого будет присваивание левой части результата вызова оператора (+) для левой и правой частей выражения.
Раз (+) для строк не изменяет состояние строки, то и (+=) не будет. Если бы (+) для строки изменял состояние строки, то изменял бы ее состояние именно он, а не последующий (=), который бы лишь присваивал ссылку.
DG>>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию. S>Оператор (==) по умолчанию для value типов относится ко внешнему контракту?
согласен на такое допущение
при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово?
DG>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию? S>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
DG>>откуда следует, что данное identity и ООП-identity — это одно и тоже? S>Тогда следует заняться более общими вопросами, например, откуда следует что объекты в C# это ООП-объекты.
DG>>>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию. S>>Оператор (==) по умолчанию для value типов относится ко внешнему контракту?
DG>согласен на такое допущение
DG>при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово?
хм, для predefined — да. Для остальных — неопределен.
DG>>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию? S>>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
DG>и в рамках какой модели это происходит?
В рамках указанного бинарного отношения эквивалентности на множестве значений ключа.
DG>>>откуда следует, что данное identity и ООП-identity — это одно и тоже? S>>Тогда следует заняться более общими вопросами, например, откуда следует что объекты в C# это ООП-объекты.
DG>а мы здесь чем занимаемся?
Путаем объекты с переменными и пытаемся понять, почему это не хорошо.
DG>>при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово? S>хм, для predefined — да.
нет, же. конечно.
вот тебе два контрпримера. в одном случае битовое представление одинаковое, но == возвращает false.
в другом случае — обратное. битовое представление различное, но сравнение одинаковое.