Re[59]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 14:06
Оценка:
G>
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?
тогда ты нарушил принцип инкапсуляции, и это уже никакого отношения к ООП не имеет.
Re[60]: Immutable object
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.12.11 14:14
Оценка:
Здравствуйте, DarkGray, Вы писали:


G>>
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) — это разные объекты

Да, это настолько очевидно что я даже не написал код для проверки

Console.WriteLine(Object.ReferenceEquals(y, y1)); //False



DG>на основании чего ты сделал все эти выводы?

DG>на основе внутреннего знания как устроены строки в .net?
DG>тогда ты нарушил принцип инкапсуляции, и это уже никакого отношения к ООП не имеет.

Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.

Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.
Re[58]: Immutable object
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.12.11 14:16
Оценка: +1
Здравствуйте, DarkGray, Вы писали:


DG>>>определи, пожалуйста, раз это легко сделать.


S>>Пардон, с наскоку не получилось сравнить структуры побитово.


DG>тогда из этого следует, что Ecma identity не может использоваться как функция идентификации объектов, потому что она нарушает инкапсуляцию объектов.


Для структур identity определяется по другому и оно не является identity в смысле ООП
Re[60]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 17:10
Оценка:
Здравствуйте, DarkGray, Вы писали:

S>>После изменения значений переменных, ссылки, которые в них хранятся, больше не указывают на один и тот же объект.


DG>как ты узнал, что они больше не ссылаются на один и тот же объект?

ReferenceEquals

DG>через ReferenceEquals? т.е. ты ReferenceEquals используешь и для проверки, что ссылки остались теми же, и для определения идентичности объектов?

Совершенно верно. Identity is implemented on System.Object via the ReferenceEquals method. (ц)

DG>но в определение явно указано, что это две разных функции: функция сравнения ссылок и функция проверки идентичности

Вообще говоря — это разные функции в широком смысле. Но разве что-то мешает определять одну через другую?

S>> Что RefEquals не может выступать в роли критерия идентичности?


DG>конечно, потому что сравнение ссылок, а не сравнение объектов, что и следует из названия

А из ECMA следует что идентичность реализована через сравнение ссылок. И именно это определяет, где один объект, а где другой.
Re[58]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 17:16
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>определи, пожалуйста, раз это легко сделать.


S>>Пардон, с наскоку не получилось сравнить структуры побитово.


DG>тогда из этого следует, что Ecma identity не может использоваться как функция идентификации объектов,

Я походу пропустил какое-то звено в рассуждениях. Следствие для меня неочевидно.

Не получилось у меня именно сравнение по memcmp структур, содержащих ссылки. Это не значит, что сравнение структур побитово невыполнимо.

DG>потому что она нарушает инкапсуляцию объектов.

А разве есть какая-то связь?
Re[61]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 20:44
Оценка:
DG>>твое "ну, понял" справедливо только при следующих утверждениях:
DG>>1) y1 и y (а также z1 и z) — это один и тот же объект
G>Присваивание ссылок очевидно сохраняет identity.

как только появляется слово "очевидно", то это означает, что человек не может объяснить происходящее.

откуда известно, что в данном месте происходит присвоение ссылок, а не что-то другое?

DG>>2) y до изменения и y после (а также z) — это разные объекты

G>Да, это настолько очевидно что я даже не написал код для проверки

G>
G>Console.WriteLine(Object.ReferenceEquals(y, y1)); //False
G>


пока не доказано, что сравнение объектов y и y1 имеет хоть какое-нибудь отношение к сравнению объекта y (до) с y (после).


G>Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.


правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?

G>Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.


является ли операция += полиморфной в C#? и если она такой является, то каким контрактом она при этом обладает?
Re[61]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 20:58
Оценка:
DG>>как ты узнал, что они больше не ссылаются на один и тот же объект?
S>ReferenceEquals

не канает.
referenceequals сравнивает ссылки на объекты, что следует из ее названия
а из различности ссылок не следует, что объекты разные.

DG>>через ReferenceEquals? т.е. ты ReferenceEquals используешь и для проверки, что ссылки остались теми же, и для определения идентичности объектов?

S>Совершенно верно. Identity is implemented on System.Object via the ReferenceEquals method. (ц)

откуда следует, что данное identity и ООП-identity — это одно и тоже?

DG>>но в определение явно указано, что это две разных функции: функция сравнения ссылок и функция проверки идентичности

S>Вообще говоря — это разные функции в широком смысле. Но разве что-то мешает определять одну через другую?

не мешает, но тогда мы получим вырожденый случай ООП, который к самому ООП имеет малое отношение (примерно такое же, какое точка имеет отношение к кругу)
Re[59]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:10
Оценка:
DG>>потому что она нарушает инкапсуляцию объектов.
S>А разве есть какая-то связь?

конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.
и соотственно, если объект не предоставляет функцию для своего побитового сравнения, то это означает, что с точки зрения ООП ты не имеешь права использовать функцию побитивого сравнения для чего либо.
Re[62]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:12
Оценка:
Здравствуйте, DarkGray, Вы писали:


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. Правда, у них есть много общего. Например, то, что отношение идентичности в них выполняет условия отношения эквивалентности.
Re[60]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:16
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>потому что она нарушает инкапсуляцию объектов.

S>>А разве есть какая-то связь?

DG>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.

Оператор (==) по умолчанию для value типов относится ко внешнему контракту?

DG>и соотственно, если объект не предоставляет функцию для своего побитового сравнения, то это означает, что с точки зрения ООП ты не имеешь права использовать функцию побитивого сравнения для чего либо.

Ну а если для побитового сравнения используется возможность рантайма?
Re[53]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:17
Оценка:
S>Она является функцией идентичности по ECMA для ссылочных типов.

если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?
Re[54]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:18
Оценка:
Здравствуйте, DarkGray, Вы писали:

S>>Она является функцией идентичности по ECMA для ссылочных типов.


DG>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?

Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
Re[62]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:24
Оценка:
Здравствуйте, DarkGray, Вы писали:

G>>Я сделал это на основании того что строки в .NET это reference типы, других соображений не нужно.


DG>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки?

Кроме тех случаев, когда работают conversion операторы. Но даже тогда, резултатом присваивания будет присваивание ссылки.

G>>Хотя сведения о том что += не изменяет строку есть в MSDN, только инкапсуляцию это никак не нарушает.


DG>является ли операция += полиморфной в C#? и если она такой является, то каким контрактом она при этом обладает?

Полиморфным является (+), а (+=) это лишь сахар, результатом которого будет присваивание левой части результата вызова оператора (+) для левой и правой частей выражения.
Раз (+) для строк не изменяет состояние строки, то и (+=) не будет. Если бы (+) для строки изменял состояние строки, то изменял бы ее состояние именно он, а не последующий (=), который бы лишь присваивал ссылку.
Re[61]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:28
Оценка:
DG>>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.
S>Оператор (==) по умолчанию для value типов относится ко внешнему контракту?

согласен на такое допущение

при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово?
Re[55]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:29
Оценка:
DG>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?
S>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.

и в рамках какой модели это происходит?
Re[63]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:30
Оценка:
DG>>откуда следует, что данное identity и ООП-identity — это одно и тоже?
S>Тогда следует заняться более общими вопросами, например, откуда следует что объекты в C# это ООП-объекты.

а мы здесь чем занимаемся?
Re[62]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:37
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>конечно. ООП утверждает, что внешняя сторона имеет право пользоваться только внешним контрактом, и не имеет право лезть в реализацию.

S>>Оператор (==) по умолчанию для value типов относится ко внешнему контракту?

DG>согласен на такое допущение


DG>при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово?

хм, для predefined — да. Для остальных — неопределен.
Re[56]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:39
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию?

S>>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.

DG>и в рамках какой модели это происходит?

В рамках указанного бинарного отношения эквивалентности на множестве значений ключа.
Re[64]: Immutable object
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.12.11 21:43
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>>>откуда следует, что данное identity и ООП-identity — это одно и тоже?

S>>Тогда следует заняться более общими вопросами, например, откуда следует что объекты в C# это ООП-объекты.

DG>а мы здесь чем занимаемся?

Путаем объекты с переменными и пытаемся понять, почему это не хорошо.
Re[63]: Immutable object
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.12.11 21:57
Оценка: 1 (1)
DG>>при этом ты утверждаешь, что оператор == для value-типов в .net сравнивает побитово?
S>хм, для predefined — да.

нет, же. конечно.
вот тебе два контрпримера. в одном случае битовое представление одинаковое, но == возвращает false.
в другом случае — обратное. битовое представление различное, но сравнение одинаковое.

     double d1 = double.NaN;
      double d2 = double.NaN;
      Console.WriteLine(d1 == d2);
      Console.WriteLine("==:{0} bits:{1} {2} {3}", d1 == d2, BitConverter.GetBytes(d1).ToHex() == BitConverter.GetBytes(d2).ToHex(), 
        BitConverter.GetBytes(d1).ToHex(), BitConverter.GetBytes(d2).ToHex());


      decimal dx = 1.0m;
      decimal dy = 1.00m;

      Console.WriteLine("==:{0} bits:{1} {2} {3}", dx == dy, dx.ToBytes().ToHex() == dy.ToBytes().ToHex(),
        dx.ToBytes().ToHex(), dy.ToBytes().ToHex());

//вспомогательный код
   public static byte[] ToBytes(this decimal d)
    {
      unsafe
      {
        byte* pd = (byte*)&d;
        var buffer = new byte[sizeof(decimal)];
        for (int i = 0; i < sizeof(decimal); ++i)
          buffer[i] = pd[i];
        return buffer;
      }
    }
    public static string ToHex(this byte[] bytes)
    {
      return string.Join("", bytes.Select(b => b.ToString("x02")).ToArray());
    }

выдача
==:False bits:True 000000000000f8ff 000000000000f8ff
==:True bits:False 00000100000000000a00000000000000 00000200000000006400000000000000
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.