Здравствуйте, igna, Вы писали:
I>Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.
Вот честное слово, как вам уже ответили ниже, "какова постановка задачи — таково и решение". Пытаться добиться вполне понятной и логичной вещи, я извиняюсь, через одно место, а потом искренне удивляться тому, что "через одно место" оно как-то криво выходит
Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею. Я жеж правильно понимаю, что симметричность вы тут согласны признать только тогда, когда "правильно" заработает метод Equal у экземпляра класса Object?
I>Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.
А она-то тут каким боком?!
Здравствуйте, gbear, Вы писали:
G>Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею.
Тут у тебя компаратор всегда один и тот же используется, независимо от типа сравниваемого объекта. Если задачу можно решить таким образом, то есть вообще без диспетчеризации, то и ООПа никакая не нужна.
Здравствуйте, samius, Вы писали:
S>Тут возможны варианты. Вполне ожидаем был бы объект, реализующий IComparer.
А, ну да. Только этот объект уже ведь не ООП объект, а просто объект (как в C). С этим (не объектно-ориентированным) решением я поностью согласен.
S>Во-первых мне довольно сложно представить задачу, решением которой был бы поиск непонятно чего в коллекции непонятно чего.
Так долгое время генериков-то в Java не было, и использовали коллекцию объектов типа Object даже если нужна была коллекция объектов одного-единственного конкретного типа.
S>Нужно только что бы откипело желание ломать эквивалентность чего-либо, написанного не тобой (в том числе стандартных строк).
Вроде я уже говорил тебе, что String точно так же "ломает эквивалентность" Object, нет?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>А, ну да. Только этот объект уже ведь не ООП объект, а просто объект (как в C). С этим (не объектно-ориентированным) решением я поностью согласен.
Что такое просто объект и чем он отличается от ООП объекта?
I>Так долгое время генериков-то в Java не было, и использовали коллекцию объектов типа Object даже если нужна была коллекция объектов одного-единственного конкретного типа.
Если коллекция объектов одного типа, то известно как искать объект этого типа, его нельзя проверять на равенство с объектами любых других типов.
I>Вроде я уже говорил тебе, что String точно так же "ломает эквивалентность" Object, нет?
Я уже отвечал, что нет.
Здравствуйте, 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? Где таки граница? В расширении файла?
Не знаю, мне все-равно. Я только пример не-ООП объектов привел, на всякий случай.
Здравствуйте, gbear, Вы писали:
G>Здравствуйте, igna, Вы писали:
G>>>Чем вас, при таком подходе, может спасти множественная диспетчеризация — я понять так и не смог... старый уже поди... тупею. I>>Поди.
G>) Ну дык просветите. Я правильно понимаю, что под симметричностью понимается не G>
G>когда "правильно" заработает метод Equal у экземпляра класса Object
G>, а что-то другое. Так? Тогда что именно?
G>Просто в .Net со всем остальным каноническое переопределение Equals/GetGashCode справляется. Вот примерно такое:
G>
G>Мне просто реально интересно, что именно, если не Object.Equals — который честно будет возвращать false, если в него передавать
экземпляр EqualToTheObject — ломает симметричность? И второй момент, каким образом, по вашему мнению, МД спасет от такого слома?
кстати надо добавить
public bool Equals(EqualToTheObject obj)
{
if (this == obj) return true;//<<==-- надо добавитьreturn _inner.Equals(obj._inner);
}
Здравствуйте, 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, и ничего про него знать не должен?
Здравствуйте, 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 объектом, без знания расширения файла.
Давай-ка соберись, и возьми где-нибудь свои слова обратно.