Re: Object.equals - Философия программирования

Здравствуйте, gbear, Вы писали:

G>Здравствуйте, igna, Вы писали:

G>>>Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею.
I>>Поди.

G>) Ну дык просветите. Я правильно понимаю, что под симметричностью понимается не
G>

G>когда "правильно" заработает метод Equal у экземпляра класса Object

G>, а что-то другое. Так? Тогда что именно?

G>Просто в .Net со всем остальным каноническое переопределение Equals/GetGashCode справляется. Вот примерно такое:

G>

 
G>class EqualToTheObject
G>{
G> private object _inner;
 
G> ...

G> /*
G> * Проверки на null сознательно опущены
G> */
G> public bool Equals(EqualToTheObject obj)
G> {
G>  return _inner.Equals(obj._inner);
G> }

G> public override bool Equals(object obj)
G> {
G>   return _inner.Equals(obj);
G> }

G> public override int GetHashCode()
G> {
G>  return _inner.GetHashCode();
G> }
G>}
G>

G>Мне просто реально интересно, что именно, если не Object.Equals — который честно будет возвращать false, если в него передавать
экземпляр EqualToTheObject — ломает симметричность? И второй момент, каким образом, по вашему мнению, МД спасет от такого слома?

кстати надо добавить

public bool Equals(EqualToTheObject obj)
{
 if (this == obj) return true;//<<==-- надо добавить
 return _inner.Equals(obj._inner);
}

Автор хочет сказать что

System.Button Button1 = new System.Button();
EqualToTheObject ETTO1 = new EqualToTheObject(Button1);
EqualToTheObject ETTO2 = new EqualToTheObject(Button1);

//тогда
  ETTO1.Equals(ETTO2) //=> true
  ETTO2.Equals(ETTO1) //=> true

  ETTO1.Equals(Button1) //=> true
  ETTO2.Equals(Button1) //=> true

//но несимметрично
  Button1.Equals(ETTO1) //=> false
  Button1.Equals(ETTO2) //=> false

Задача (Java): Определить класс EqualToTheObject, экземпляр которого ссылается на экземпляр класса Object, и переопределяет equals таким образом, что equals возвращает true тогда и только тогда, когда его аргумент является тем же экземпляром класса Object, на который ссылается this, или экземпляром класса EqualToTheObject ссылающегося на тот же экземпляр класса Object, на который ссылается this.

Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

Аналогично для .NET.

Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.

Здравствуйте, igna, Вы писали:

I>Задача (Java): Определить класс EqualToTheObject, экземпляр которого ссылается на экземпляр класса Object, и переопределяет equals таким образом, что equals возвращает true тогда и только тогда, когда его аргумент является тем же экземпляром класса Object, на который ссылается this, или экземпляром класса EqualToTheObject ссылающегося на тот же экземпляр класса Object, на который ссылается this.

I>Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

I>Аналогично для .NET.

I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.

мысля в этом направлении, можно прийти к тому, что отсутствие рациональных чисел делает невозможным, например,
решение уравнений типа 2*X = 5, если так, то вся эта сраная целочисленная математика ущербна в самом своем корне.

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

Здравствуйте, igna, Вы писали:

I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.

А причем тут единая иерархия? обобщи задачу, вместо object введи тип-параметр T и придумай тип A<T> и функцию (A<T>, T) -> bool чтобы оно было отношением эквивалентности.

Как видишь даже из типа функции такого сделать нельзя. Можно сделать функцию (T,V) -> bool, внутри которой выполнять typetest. Но для разных A<T> это будут разные функции и ты не сможешь написать один код который будет всегда работать.

Здравствуйте, igna, Вы писали:

I>Ну так оно же и "для более прямолинейных сценариев" через одно место. Даже при минимуме собственно логики сравнения все-равно строк десять вокруг да около.
Да, ну, брось. Даже в самом наивном сценарии это +4 строки на проверку типа и typecast:

public override bool Equals(object other)
{
  if (!(other is MyType))
  {
    return false;
  }
  var myTypeOther = (MyType)other;
  .... твой код
}

Но этот паттерн можно устранить, введя дополнительную функцию:

public static bool EqualsHelper<T>(this object other, Func<T, bool> predicate)
{
  return other is T ? predicate((T)other) : false;
}

Тогда все методы сравнения будут иметь вид:

public override bool EqualsHelper(object other)
{
  return other.Equals<MyType>(_ => ...);
}

Здравствуйте, igna, Вы писали:

I>Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

Вот честное слово, как вам уже ответили ниже, "какова постановка задачи — таково и решение". Пытаться добиться вполне понятной и логичной вещи, я извиняюсь, через одно место, а потом искренне удивляться тому, что "через одно место" оно как-то криво выходит

Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею. Я жеж правильно понимаю, что симметричность вы тут согласны признать только тогда, когда "правильно" заработает метод Equal у экземпляра класса Object?

I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.
А она-то тут каким боком?!

"ущербная" это эмоциональная оценка.
а то что есть проблемы всем давно известно.

Здравствуйте, hardcase, Вы писали:

H>Вы поставили бестолковую задачу и сделали бестолковый вывод.

Это переопределение equals бестолковая задача? Бестолково тут ООП в Java/.NET, где переопределение equals и так гораздо сложнее чем оно должно быть, а тут вообще пример задачи, решить которую невозможно.

Здравствуйте, cvetkov, Вы писали:

C>а то что есть проблемы всем давно известно.

Вот прям так уж "всем" и "давно". Лучше стало чем 10 лет тому назад, это да.

Здравствуйте, Chrome, Вы писали:

C>мысля в этом направлении, можно прийти к тому, что отсутствие рациональных чисел делает невозможным, например,
C>решение уравнений типа 2*X = 5, если так, то вся эта сраная целочисленная математика ущербна в самом своем корне.

Так ты не мысли так. Целочисленная математика в отличие от ООПни никогда не обещала решить все проблемы. А диспетчеризация в Java и .NET только по одному параметру это просто техническое ограничение, и по хорошему надо так об этом и говорить, а не делать вид, что все окей. Не окей никак, поскольку такой фундаментальный метод как equals требует двойной диспетчеризации.

двойная диспетчеризация решит этот частный случай, но добавит столько головной боли что просто ужас.
поэтомц сейчас просто предпочитают нормально дизайнить внутри ооп.

Здравствуйте, cvetkov, Вы писали:

C>двойная диспетчеризация решит этот частный случай, но добавит столько головной боли что просто ужас.

Какой такой боли?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, cvetkov, Вы писали:
C>>двойная диспетчеризация решит этот частный случай, но добавит столько головной боли что просто ужас.
I>Какой такой боли?
сложно понять какой конкретно метод вызовется.

Здравствуйте, igna, Вы писали:

I>Аналогично для .NET.
I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.
Какой практический вывод из этих рассуждений?
Означает ли это, что все языки, не поддерживающие мультиметодов — сраные и ущербные?

Здравствуйте, 0x7be, Вы писали:

0>Означает ли это, что все языки, не поддерживающие мультиметодов — сраные и ущербные?

Нет, только те из них, которые всё производят от класса Object и определяют в нем метод equals, который сами же не позволяют переопределять по-человечески, нарушая таким образом простое житейское правило: "Не можешь срать, не мучай жопу".

Здравствуйте, igna, Вы писали:

0>>Означает ли это, что все языки, не поддерживающие мультиметодов — сраные и ущербные?
I>Нет, только те из них, которые всё производят от класса Object и определяют в нем метод equals, который сами же не позволяют переопределять по-человечески, нарушая таким образом простое житейское правило: "Не можешь срать, не мучай жопу".
Ладно, а что там насчет практических выводов?

Здравствуйте, 0x7be, Вы писали:

0>Ладно, а что там насчет практических выводов?

Практические выводы просты, дизайнерам языков — не повторять ошибок, программистам — по возможности не использовать языков, в которых повторены ошибки. То есть, если например в каком-нибудь D классы унаследованы от Object, а последний имеет метод opEquals(Object o), то и пусть себе идет этот D.

Здравствуйте, gandjustas, Вы писали:

G>А причем тут единая иерархия? обобщи задачу, вместо object введи тип-параметр T и придумай тип A<T> и функцию (A<T>, T) -> bool чтобы оно было отношением эквивалентности.

G>Как видишь даже из типа функции такого сделать нельзя. Можно сделать функцию (T,V) -> bool, внутри которой выполнять typetest. Но для разных A<T> это будут разные функции и ты не сможешь написать один код который будет всегда работать.

Извини, не понял, что ты сказать-то хотел. Можно суть одним предложением, например: "Задача не решается независимо от наличия или отсутствия мультиметодов"?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>А причем тут единая иерархия? обобщи задачу, вместо object введи тип-параметр T и придумай тип A<T> и функцию (A<T>, T) -> bool чтобы оно было отношением эквивалентности.

G>>Как видишь даже из типа функции такого сделать нельзя. Можно сделать функцию (T,V) -> bool, внутри которой выполнять typetest. Но для разных A<T> это будут разные функции и ты не сможешь написать один код который будет всегда работать.

I>Извини, не понял, что ты сказать-то хотел. Можно суть одним предложением, например: "Задача не решается независимо от наличия или отсутствия мультиметодов"?

Я написал чтобы ты это сказал.

Здравствуйте, gandjustas, Вы писали:

I>>Извини, не понял, что ты сказать-то хотел. Можно суть одним предложением, например: "Задача не решается независимо от наличия или отсутствия мультиметодов"?

G>Я написал чтобы ты это сказал.

Ну а я этого не говорю.

Здравствуйте, igna, Вы писали:

I>Практические выводы просты, дизайнерам языков — не повторять ошибок, программистам — по возможности не использовать языков, в которых повторены ошибки. То есть, если например в каком-нибудь D классы унаследованы от Object, а последний имеет метод opEquals(Object o), то и пусть себе идет этот D.
Не вижу смысла отказываться от языка по этой причине. Для меня главный критерий оценки языка — это то, насколько я успешно решаю на нем свои задачи. Не вижу каким образом наличие Object.Equals мне может помешать.

Менее абстрактная задача:

Определить класс SpaceInsensitiveString, при сравнении двух объектов которого метод equals считает две любые последовательности пробелов равными. Дополнительно объект этого класса должен быть равным объекту класса String, текстовое содержание которого равно текстовому содержанию сравниваемого объекта SpaceInsensitiveString, где последовательности пробелов заменены единичными пробелами.

Задача опять же непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

Здравствуйте, igna, Вы писали:

I>Менее абстрактная задача:

I>Определить класс SpaceInsensitiveString, при сравнении двух объектов которого метод equals...

I>Задача опять же непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.
Это не задача, это решение. Причем не очень удачное в том плане, что требует изменения классов эквивалентности строк. Тут дело даже не в ООП, а в желании нарушить эквивалентность.

Все равно что "хочу написать объект, который будет равен всему, и до фени что перестанет работать половина FCL".

Здравствуйте, samius, Вы писали:

S>Все равно что "хочу написать объект, который будет равен всему, и до фени что перестанет работать половина FCL".

Ну зачем передергивать-то, какому всему?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Все равно что "хочу написать объект, который будет равен всему, и до фени что перестанет работать половина FCL".

I>Ну зачем передергивать-то, какому всему?

А где грань между тем что бы сломать эквивалентность только строк или вообще Object-ам?

Здравствуйте, samius, Вы писали:

S>А где грань между тем что бы сломать эквивалентность только строк или вообще Object-ам?

Используя твою терминологию, String.equals "ломает эквивалентность Object-ам".

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>А где грань между тем что бы сломать эквивалентность только строк или вообще Object-ам?

I>Используя твою терминологию, String.equals "ломает эквивалентность Object-ам".
Это не так. Ни при каких обстоятельствах String.Equals(object) не вернет true, если object не является экземпляром класса String. Точно так же Object.Equals(object) не вернет true если object является экземпляром класса String.
А вот неверным образом перекрытый Object.Equals(object) может вернуть true для строки. Но этот случай не попадает под "String.equals ломает эквивалентность".

Здравствуйте, samius, Вы писали:

S>Ни при каких обстоятельствах String.Equals(object) не вернет true, если object не является экземпляром класса String.

Это ограничение надуманно и вызвано исключительно неполноценностью классического ООП без мультиметодов.

Здравствуйте, igna, Вы писали:

I>Менее абстрактная задача:
I>Определить класс SpaceInsensitiveString, при сравнении двух объектов которого метод equals считает две любые последовательности пробелов равными. Дополнительно объект этого класса должен быть равным объекту класса String, текстовое содержание которого равно текстовому содержанию сравниваемого объекта SpaceInsensitiveString, где последовательности пробелов заменены единичными пробелами.
I>Задача опять же непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.
Вообще-то, задачи типа "сравнивать строки хитровыдуманным способом" легко решаются иначе, путем введения статического метода/класса стратегии.
Нет никакой нужды для решения этой конкретной задачи вводить свой класс строки и сравнивать его со стандартным классом.
Это я к чему: в реальном проекте описанная тобой проблема яйца выеденного не стоит.

Здравствуйте, 0x7be, Вы писали:

0>Вообще-то, задачи типа "сравнивать строки хитровыдуманным способом" легко решаются иначе, путем введения статического метода/класса стратегии.
0>Нет никакой нужды для решения этой конкретной задачи вводить свой класс строки и сравнивать его со стандартным классом.
0>Это я к чему: в реальном проекте описанная тобой проблема яйца выеденного не стоит.

Возможно. Просто привел пример показывающий ущербность популярных ООП языков. А проблемы в реальных проектах все-таки возникают, например переопределение того же equals в более реалистических ситуациях, просто проблемы эти все-таки решаемы, хоть и через одно место.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Ни при каких обстоятельствах String.Equals(object) не вернет true, если object не является экземпляром класса String.

I>Это ограничение надуманно и вызвано исключительно неполноценностью классического ООП без мультиметодов.
Это ограничение гарантирует неразрушимость штатной эквивалентности строк, что вобщем-то соответствует здравому смыслу.
Соглашусь лишь с тем, что делать эквивалентность методом экземпляра было недоразумением.

Здравствуйте, igna, Вы писали:

I>Возможно. Просто привел пример показывающий ущербность популярных ООП языков. А проблемы в реальных проектах все-таки возникают, например переопределение того же equals в более реалистических ситуациях, просто проблемы эти все-таки решаемы, хоть и через одно место.
Я достаточно много писал на C# и у меня к нему есть свои претензии, однако на ЭТУ проблему так ни разу и не наткнулся.

Здравствуйте, 0x7be, Вы писали:

0>Я достаточно много писал на C# и у меня к нему есть свои претензии, однако на ЭТУ проблему так ни разу и не наткнулся.

Equals не переопределял?

Здравствуйте, samius, Вы писали:

S>Соглашусь лишь с тем, что делать эквивалентность методом экземпляра было недоразумением.

Ну так это уже полдела! Чем же его надо было делать, статическим методом? Как тогда искать в коллекции объектов?

Здравствуйте, igna, Вы писали:

0>>Я достаточно много писал на C# и у меня к нему есть свои претензии, однако на ЭТУ проблему так ни разу и не наткнулся.
I>Equals не переопределял?
Вот именно так, как пишешь ты, что бы пробросить отношение равенства между разными типами, нет.
Вообще не припомню, что бы у меня такая потребность возникала хоть раз.
А для более прямолинейных сценариев переопределял и весьма успешно.

Здравствуйте, 0x7be, Вы писали:

0>А для более прямолинейных сценариев переопределял и весьма успешно.

Ну так оно же и "для более прямолинейных сценариев" через одно место. Даже при минимуме собственно логики сравнения все-равно строк десять вокруг да около.

Здравствуйте, igna, Вы писали:

I>Ну так это уже полдела! Чем же его надо было делать, статическим методом? Как тогда искать в коллекции объектов?

var myInstance = MyCollection.First(_ => MyComparerStaticClass.Compare(_, myValueToCompare));

Не?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Соглашусь лишь с тем, что делать эквивалентность методом экземпляра было недоразумением.

I>Ну так это уже полдела! Чем же его надо было делать, статическим методом?
Тут возможны варианты. Вполне ожидаем был бы объект, реализующий IComparer.

I>Как тогда искать в коллекции объектов?
Во-первых мне довольно сложно представить задачу, решением которой был бы поиск непонятно чего в коллекции непонятно чего. Скажем так, валить в одну коллекцию кнопки, строки, делегаты и файлы — форменное безумие. В остальном же несложно указать методу поиска соответствующий способ сравнения объектов.

Что касается форменного безумия — и эту задачу можно было решить красиво на уровне проектирования фреймворка. Например, можно было бы к типу объекта каким-то образом привязать дефаултный компарер для экземпляров этого типа. Возможно атрибутом (как конвертер типа) или виртуальным методом
IComparer Object.GetDefaultComparer()

Тогда для поиска неизвестно чего среди коллекции неизвесно чего можно было бы запросить компарер для искомого объекта и искать этим компарером. Результат был бы не хуже, чем при существующем дизайне. В частности, можно было бы построить эквивалентность для строк и SpaceInsensitiveString, но отличную от эквивалентности строк. Компарер с указанной эквивалентностью можно подать в любой метод поиска. Только не рассказывай что задача требует найти строку среди коллекции неизвестно чего, в чем может быть SpaceInsensitiveString, и об этом не знает программист, который делает вызов поиска, и ему в голову не приходит подсунуть соответствующий компарер. Попробуй выдумать не высосанную из пальца задачу, которая бы потребовала такого решаения.
Кстати, ничто не мешает писать свои IComparer и сейчас. Нужно только что бы откипело желание ломать эквивалентность чего-либо, написанного не тобой (в том числе стандартных строк).

Здравствуйте, igna, Вы писали:

I>Задача (Java): Определить класс EqualToTheObject, экземпляр которого ссылается на экземпляр класса Object, и переопределяет equals таким образом, что equals возвращает true тогда и только тогда, когда его аргумент является тем же экземпляром класса Object, на который ссылается this, или экземпляром класса EqualToTheObject ссылающегося на тот же экземпляр класса Object, на который ссылается this.

I>Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

I>Аналогично для .NET.

I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.

То, что классовая иерархия создает не мало проблем — спору нет. Но и мультиметоды тоже не так уж и пушисты. Посмотрите на кложуру. Там без фанатизма к ним относятся, говорят, что не всегда они удобны, они могут и существенно код усложнить, запутать. Кроме того, создают они и технические проблемы — проседание по перфомансу, что не дает возможность реализовать кложуру на кложуре. Недавно им ввели альтернативу — протоколы для типов. Там диспетчеризация — только по первому параметру. Но классов и ООП в кложуре не требуют (классы там, фактически, только для дружбы с жабой), типы и протоколы похожи на структуры и интерфейсы (как в Go), или на хаскелевские классы типов. Концептуально выглядят симпатично, кложуровцы очень как бы намекают, что смотреть лучше именно на протоколы, и не только из-за лучшей производительности.

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

очень просто -- коллекция непонятно чего появляется как результат сериализации всего для записи на диск

т.е. есть у нас сериализованная-на-диск-фигня -- ну допустим целая вкладка браузера с огромной кучей классов, отвечающих за ui, html, css, историей запросов (чтобы было десериализовав пройти назад)... и вот захотелось нам найти что-то там конкретное

Здравствуйте, m e, Вы писали:

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

ME>очень просто -- коллекция непонятно чего появляется как результат сериализации всего для записи на диск
На сколько я понимаю процесс сериализации, результатом его является коллекция понятно чего — байт.

ME>т.е. есть у нас сериализованная-на-диск-фигня -- ну допустим целая вкладка браузера с огромной кучей классов, отвечающих за ui, html, css, историей запросов (чтобы было десериализовав пройти назад)... и вот захотелось нам найти что-то там конкретное
найти что-то конкретное в потоке байт — не вопрос. Надо только знать, что искать. Но смысл такого поиска от меня ускользает.

Предположу что задача состоит в том что бы найти что-то конкретное в коллекции десериализованной фигни. Не могу удержаться от комментария на тему "нафига было пихать всю фигню в одну коллекцию".
Так вот, что бы что-то найти (с помощью Object.Equals) нужно очень конкретно знать, что мы ищем. Правильный Equals должен быть устроен так, что бы мы не просто могли найти класс, отвечающий за ui, а что бы мы могли отличать один класс, отвечающий за ui от другого.
a) Если это не так, то уместен вопрос, а нафига нужно было такую эквивалентность запихивать в Equals? Ведь нам нужно найти что-то, в действительности не равное конкретному экземпляру, а удовлетворяющее некоторому свойству (или свойсту типа), т.е. collection.Find(v => v is IMyUI). Использовать для такого рода поиска перекрытый Equals — очень неудачное решение.
b) В свою очередь, если нужно найти конкретную фигню с конкретными свойствами корректно равную заданной фигне, то видимо что конкретно заданная фигня у нас уже есть, именно ее мы будем искать в коллекции. Но такой поиск много смысла не имеет, он может ответить лишь на вопрос, а есть ли такая фигня в коллекции, какой у нее индекс. Отвечать на такой вопрос можно куда более эффективно, если информация будет организована чуть лучше, чем коллекция всякой фигни.

Т.е. тема "нафига нужна коллекция всякой фигни и поиск в ней именно по equals" не раскрыта.

Здравствуйте, gbear, Вы писали:

G>Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею.

Поди.

Здравствуйте, 0x7be, Вы писали:

0>var myInstance = MyCollection.First(_ => MyComparerStaticClass.Compare(_, myValueToCompare));

0>Не?

Не.

Тут у тебя компаратор всегда один и тот же используется, независимо от типа сравниваемого объекта. Если задачу можно решить таким образом, то есть вообще без диспетчеризации, то и ООПа никакая не нужна.

Здравствуйте, samius, Вы писали:

S>Тут возможны варианты. Вполне ожидаем был бы объект, реализующий IComparer.

А, ну да. Только этот объект уже ведь не ООП объект, а просто объект (как в C). С этим (не объектно-ориентированным) решением я поностью согласен.

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

Так долгое время генериков-то в Java не было, и использовали коллекцию объектов типа Object даже если нужна была коллекция объектов одного-единственного конкретного типа.

S>Нужно только что бы откипело желание ломать эквивалентность чего-либо, написанного не тобой (в том числе стандартных строк).

Вроде я уже говорил тебе, что String точно так же "ломает эквивалентность" Object, нет?

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>А, ну да. Только этот объект уже ведь не ООП объект, а просто объект (как в C). С этим (не объектно-ориентированным) решением я поностью согласен.
Что такое просто объект и чем он отличается от ООП объекта?

I>Так долгое время генериков-то в Java не было, и использовали коллекцию объектов типа Object даже если нужна была коллекция объектов одного-единственного конкретного типа.
Если коллекция объектов одного типа, то известно как искать объект этого типа, его нельзя проверять на равенство с объектами любых других типов.

I>Вроде я уже говорил тебе, что String точно так же "ломает эквивалентность" Object, нет?
Я уже отвечал, что нет.

Здравствуйте, samius, Вы писали:

S>Что такое просто объект и чем он отличается от ООП объекта?

Вот к примеру определение C:

object

region of data storage in the execution environment, the contents of which can represent values

Ну и вообще в смысле нормального русского языка как в предложении: "Субъект в темных очках взял объект под наблюдение."

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Вот к примеру определение C:

I>

I>region of data storage in the execution environment, the contents of which can represent values

Каким образом это определение исключает ООП объекты?

Здравствуйте, igna, Вы писали:

G>>Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею.
I>Поди.

Ну дык просветите. Я правильно понимаю, что под симметричностью понимается не

когда "правильно" заработает метод Equal у экземпляра класса Object

, а что-то другое. Так? Тогда что именно?

Просто в .Net со всем остальным каноническое переопределение Equals/GetGashCode справляется. Вот примерно такое:

class EqualToTheObject
{
 private object _inner;
 
 ...

 /*
 * Проверки на null сознательно опущены
 */
 public bool Equals(EqualToTheObject obj)
 {
  return _inner.Equals(obj._inner);
 }

 public override bool Equals(object obj)
 {
   return _inner.Equals(obj);
 }

 public override int GetHashCode()
 {
  return _inner.GetHashCode();
 }
}

Мне просто реально интересно, что именно, если не Object.Equals — который честно будет возвращать false, если в него передавать экземпляр EqualToTheObject — ломает симметричность? И второй момент, каким образом, по вашему мнению, МД спасет от такого слома?

Здравствуйте, samius, Вы писали:

S>Каким образом это определение исключает ООП объекты?

Оно их не исключает. Суть в том, что объекты в C есть, но поскольку C не является ОО-языком, то соответственно и объекты в нем не ООП объекты. Просто как пример того, что такие не-ООП объекты бывают.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Каким образом это определение исключает ООП объекты?

I>Оно их не исключает. Суть в том, что объекты в C есть, но поскольку C не является ОО-языком, то соответственно и объекты в нем не ООП объекты. Просто как пример того, что такие не-ООП объекты бывают.

Т.е. struct в C объектом не будет, а тот же самый struct в C++ станет объектом просто потому что C++ является ОО-языком? Или в C++ объектом считается то что class? Где таки граница? В расширении файла?

Здравствуйте, gbear, Вы писали:

G>Я правильно понимаю, что под симметричностью понимается не

G>когда "правильно" заработает метод Equal у экземпляра класса Object

G>, а что-то другое. Так? Тогда что именно?

Из a.Equals(b) следует b.Equals(a) и наоборот.

G>Мне просто реально интересно, что именно, если не Object.Equals — который честно будет возвращать false, если в него передавать экземпляр EqualToTheObject — ломает симметричность?

Ну если одновременно EqualToTheObject.Equals, если в него передавать экземпляр Object, будет возвращать true, то симметричность поломана.

G>И второй момент, каким образом, по вашему мнению, МД спасет от такого слома?

При выборе (в runtime) подходящего метода Equals будут учитываться типы обоих аргументов, соответственно, если хотя бы один из них окажется EqualToTheObject, будет выбран "мой новый" метод, а не тот, который есть в библиотеке.

Здравствуйте, igna, Вы писали:

I>Тут у тебя компаратор всегда один и тот же используется, независимо от типа сравниваемого объекта. Если задачу можно решить таким образом, то есть вообще без диспетчеризации, то и ООПа никакая не нужна.
Сказать по правде, мне ООПа с полиморфизмом в подобных вещах ещё ни разу не потребовалась

Здравствуйте, samius, Вы писали:

S>Т.е. struct в C объектом не будет, а тот же самый struct в C++ станет объектом просто потому что C++ является ОО-языком? Или в C++ объектом считается то что class? Где таки граница? В расширении файла?

Не знаю, мне все-равно. Я только пример не-ООП объектов привел, на всякий случай.

Здравствуйте, 0x7be, Вы писали:

0>Сказать по правде, мне ООПа с полиморфизмом в подобных вещах ещё ни разу не потребовалась

Да по правде сказать, она вообще не так уж часто бывает нужна.

Здравствуйте, igna, Вы писали:

I>Из a.Equals(b) следует b.Equals(a) и наоборот.

Ну т.е. если допустить, что b — это экземпляр класса Object, то таки Object.Equals работает нарушая симметричность

G>>И второй момент, каким образом, по вашему мнению, МД спасет от такого слома?

I>При выборе (в runtime) подходящего метода Equals будут учитываться типы обоих аргументов, соответственно, если хотя бы один из них окажется EqualToTheObject, будет выбран "мой новый" метод, а не тот, который есть в библиотеке.

Это-то все понятно... что такое МД — я в курсе. Мне просто интересно, вы-то понимаете, что означает наличие такого "подходящего метода Equals" _в классе Object_, который, на минуточку, вообще-то предок EqualToTheObject, и ничего про него знать не должен?

По этому вам и говорят, что вы выдали крайне не удачное решение какой-то задачи, за саму задачу. И удивляетесь, что оно кривое.

Что мешает, например, переопределить ==/!= для EqualToTheObject? В этом случае с симметричностью проблем никаких.

Здравствуйте, gbear, Вы писали:

G>Мне просто интересно, вы-то понимаете, что означает наличие такого "подходящего метода Equals" _в классе Object_, который, на минуточку, вообще-то предок EqualToTheObject, и ничего про него знать не должен?

В том-то и дело, что он не в классе Object.

Здравствуйте, igna, Вы писали:

0>>Сказать по правде, мне ООПа с полиморфизмом в подобных вещах ещё ни разу не потребовалась

I>Да по правде сказать, она вообще не так уж часто бывает нужна.
Именно

Лично я на С# программирую в гибридном стиле, сочетающим ОО и функциональный подходы, причем в ОО-части я избегаю наследования реализации.
Интерфейсы — наше все

P.S. Я вообще, скорее, скептичести отношусь к ООП. Однако твоего революционного настроя в стиле "... на свалку!" не разделяю.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Т.е. struct в C объектом не будет, а тот же самый struct в C++ станет объектом просто потому что C++ является ОО-языком? Или в C++ объектом считается то что class? Где таки граница? В расширении файла?

I>Не знаю, мне все-равно. Я только пример не-ООП объектов привел, на всякий случай.
А по-моему было все немного по-другому.
1) Ты сказал что объект, реализующий IComparer — это не объект

Только этот объект уже ведь не ООП объект, а просто объект (как в C).

2) потом

Суть в том, что объекты в C есть, но поскольку C не является ОО-языком, то соответственно и объекты в нем не ООП объекты.

3) На вопрос об уточнении правил критерия для разных языков, ты говоришь что тебе все равно.

Т.е. ты выдвигаешь критерии, которыми сам не пользуешься. Объект, реализующий IComparer написан на C# (на ОО-языке), но ты его назвал "просто объектом", а не ОО. С другой стороны, твой критерий не позволяет узнать, является ли struct объектом, без знания расширения файла.

Давай-ка соберись, и возьми где-нибудь свои слова обратно.

От:	hardcase	http://nemerle.org
Дата:	10.02.12 11:31
Оценка:	1 (1) +1 -1

	От:	icWasya
	Дата:	14.02.12 10:19
	Оценка:	4 (1)

	От:	igna
	Дата:	10.02.12 09:54
	Оценка:	-1

	От:	Chrome
	Дата:	10.02.12 11:46
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	10.02.12 17:58
Оценка:	+1

От:	samius	http://sams-tricks.blogspot.com
Дата:	12.02.12 09:03
Оценка:

	От:	0x7be
	Дата:	13.02.12 16:58
	Оценка:

	От:	0x7be
	Дата:	11.02.12 09:43
	Оценка:

	От:	0x7be
	Дата:	13.02.12 13:18
	Оценка:

	От:	0x7be
	Дата:	13.02.12 13:32
	Оценка: