DoSOfRedRiver,
Тот случай когда хотел сумничать а в результате пернул в лужу. Причём тут вообще свойства массива? Речь исключительно о данных внутри, гетерогенность которых приводит к необходимости делать проверку типа в коде.

DoSOfRedRiverЯ тоже вот что-то такое подумал, когда твоё сообщение прочитал.

Что-то подумал, но не понял что?

DoSOfRedRiverГде тут гетерогенность то?
В данных. Сколько раз это нужно написать чтобы до тебя дошло?

DoSOfRedRiverЧем ссылка на Object отличается от ссылки на Object, а? Чо теперь, любая ковариантная коллекция в Джаве стала гетерогенной ?
У тебя ещё и с логикой туго? То что коллекция может содержать гетерогенные данные ещё не значит что данные в ней действительно гетерогенные. И то что данные гетерогенные в данном конкретном случае, ещё не значит что все коллекции имеют гетерогенные данные. Урок логики окончен. Переваривай.

Сергей АрсеньевВместо того, чтобы спорить о том, какой термин глубже объясняет смысл природы вещей, объяснил бы чем проверка на instance of отличается от проверки значения поля?
Да, прописные истины , вроде

From Effective C++, by Scott MeyersAnytime you find yourself writing code of the form "if the object is of type T1, then do something, but if it's of type T2, then do something else," slap yourself

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

Сергей АрсеньевИли ты предлагаешь хранить в коллекциях только абсолютно тождественные объекты?

И эти люди предлагают мне не спорить о терминологии. "Тождественность" здесь каким боком вообще. Я предлагаю не хранить в коллекциях объекты разных типов. Если у тебя массив типа Object, то оперировать ты должен только методами типа Object с этим массивом. Если тебе приходится смотреть внутрь каждого объекта, чтобы понять можешь ли ты им оперировать, то значит где-то ты уже наговнокодил.

Сергей Арсеньев Может TC действие, в котором важно, что там строка или не строка важно только раз в год.
А во всех остальных случаях нужен именно Object.
Может это уже обсуждение сферических коней в вакууме? Частота выполнения кода как относится к его качеству вообще? Или опять качество меряем производительностью?

DoSOfRedRiver,

Натянул сову на глобус. Молодец.

DoSOfRedRiverМожно узнать, что это за отношение гетерогенности такое?
То самое, которое требует instanceof String

DoSOfRedRiverОн [массив] не является гетерогенным, не содержит "гетерогенных данных".
Весь интернет пользуется, а у тебя "не является".
http://stackoverflow.com/questions/16363547/how-to-declare-an-array-of-different-data-types

DoSOfRedRiverЧто такое гетерогенная коллекция я уже объяснил.
Объяснил он. Теперь гуглу объясни:
https://www.google.com/search?q=define: heterogenous collection
https://wiki.haskell.org/Heterogenous_collections Does some kind of collection of objects with different types in Haskell exist?
Вопросы?

DoSOfRedRiverЕсть что по существу возразить?

Ты тут не первый кто пытается таким способом самоутвердится. Но уж если обосрался, имей смелость в этом признаться хотя бы себе.

DoSOfRedRiverСлушай, ты меня утомил.

Хорошая попытка вызвать жалость. Но нет.

DoSOfRedRiverА это твоё отношение как-то записывается, или оно только в твоей голове существует, и на математический язык не перекладывается?
Какой нахрен математический язык? Мы тут что дисер защищаем?

DoSOfRedRiverКлассно, выдрал цитатку из статьи про ДРУГОЙ ЯЗЫК который НЕ ПОДДЕРЖИВАЕТ ООП. Я могу тебе эссе на "Идиота" Достоевского запостить сюда.

Тебе удобно не замечать всех остальных ссылок из гугла. Ну, что же. Бывает. ООП тут вообще при чем??? Типизация есть? Так вот речь о ней.

DoSOfRedRivertuples vs lists:
Tuples - Heterogeneous
Lists - Homogeneous
А вот это уже конкретика хаскеля. Но тебя этот факт мало волнует. Ты готов за любую нелепость зацепиться?

DoSOfRedRiverТы так и не ответил на вопрос:
DoSOfRedRiverЧо теперь, любая ковариантная коллекция в Джаве стала гетерогенной?
Ты так и не понял ответ. Речь не о коллекции как типе и её свойствах, речь о коллекции как наборе данных.

DoSOfRedRiverЕсли так, то можешь не отвечать дальше, нам не о чем поговорить будет.
Ну, так и не истери, если тебе не о чем говорить.

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

А вот никому не известный автор
http://www.k-press.ru/cs/2008/3/generic/generic.asp Теория и практика Java. Эксперименты с generic-методами
Автор: Брайен Гетц
...
С другой стороны, raw-тип List является гетерогенным;
...

Оригинал, если вдруг кто-то решит что это отсебятина переводчика
http://www.ibm.com/developerworks/library/j-jtp04298/

Ну, что? Тут уже не так просто ляпнуть, что Хаскель это не ООП язык, поэтому термины типизации там совсем не такие?

DoSOfRedRiver,

Всё я понял, причину твоего заблуждения. Ты увидел, что тип параметра Object[], и ты знаешь что это не очень хорошо и решил что именно по этой причине я называю такой массив гетерогенным. А это не так. Object[] это, конечно, не очень хорошо, но это не корень проблемы, а её следствие. Проблема в том что автор в этом массиве хранит гетерогенную коллекцию, которая требует от него явных проверок на тип. Это ключевая проблема. То есть речь идёт не о коллекции-типе, как тебе показалось, а о коллекции-объекте, как состоянии. И это не только ключевая проблема, но и на много более критичная проблема, по сравнению с использованием типа Object[]. Что тоже не фонтан, но, не вызывает таких проблем.

Сергей Арсеньев Этак мы дойдем до - нафиг нужно наследование?

Для наследования есть полиморфизм, который проблему решает.

Сергей Арсеньев Если у людей вся логика построена на вызове метода hashCode() и equals()
Когда вся логика построена на hashCode() и equals(), то список у нас условно гомогенный. Когда человеку нужно писать if(o instanceof String), то список резко становиться гетерогенным. Потому что для нас по критерию String/не String уже как минимум два разных типа.

Сергей Арсеньев Или вообще это коллекция со списком мониторов. Зачем им разные списки?
Зачем монитору toLowerCase()?

Сергей Арсеньев Да ТС может захотел на время засунуть туда логгер для строк - ему надо проверять строка не строка. Но основную логику перефигачивать ради такой задачи глупо, IMHO.
Глупо потом писать if ... instanceof в каждом методе где используется эта коллекция.

Сергей АрсеньевP.S. Да и свалка у ТС могла возникнуть по наследству. В этом случае совет - это плохо равнозначен совету игроку в тетрис - не туда надо было. :)
И автор вместо того чтобы разгрести свалку переводит код на стримы. Да?

13-й ПилигримА toLowerCase нужен для регистронезависимого поиска.
Спасибо за разъяснения, но они никак не объясняют надобности в гетерогенных значениях для поиска.
field у вас один. Значит все values должны соответствовать его типу. Так ведь? Значит там либо все String, либо все Integer, либо все значения другого одинакового типа. Поэтому вполне можно, например, через method overload конструировать SearchBean для String не так как для других типов (с нормализацией регистра). Из каких данных вы этот SearchBean собираете? Почему там не String[], например?
Как у вас в values может попасть одновременно String и другой тип?

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

13-й ПилигримДа, этот вариант выглядит предпочтительным.

Скажем решительное "нет" копипасте и "да" самодокументированому коду.

Blazkowicz

А может и так.

Сергей Арсеньев,

Это не сервис же.