для случаев когда лень создавать новый бесполезный класс враппера для 2х объектов

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

оперируйте доменными понятиями и таких потребностей не будет...

оперируйте доменными понятиями и таких потребностей не будет...

о ну давайте плодить сущности без необходимости

ну правильно, для того чтобы сделать код нечитаемым есть Map.Entry вместо Pair

ну да, а потом вызывать безымянные getFirst(), getSecond() что бы потом читатель думал, а что это еще за хрень

о ну давайте плодить сущности без необходимости

такого тоже не должно быть

такого тоже не должно быть

окей, простой пример

есть абстрактная парная херня

икс игрек например

для нее че отдельный класс писать?

или латитуда лонгитуда

да таких примеров полно

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

возможно не вылазит даже за пределы метода

икс игрек например

Coordinate

или латитуда лонгитуда

тоже самое

для этого есть Map.Entry

т.е. переопределять каждый раз?

сущьность с именем :)

т.е. переопределять каждый раз?

HashMap.Entry

но это все костыли

Coordinate

у тебя икс это уже допустим объект чего-то там

так что координата не подойдет

)

для нее че отдельный класс писать?

и все таки в ООП надо работать с доменами, вся эта фпшнина лишняя

и все таки в ООП надо работать с доменами, вся эта фпшнина лишняя

и что ты подразумеваешь под словом "домен"?

Нафиг Pair, даёшь сразу Tuple

я даже спорить дальше не буду :)

еще раз, у тебя внутри одного метода нужен вспомогательный класс

и что ты подразумеваешь под словом "домен"?

модель

причем тут домен вообще

Я думаю, что разрабы языка явно умнее, чем многие в этом чате

еще раз, у тебя внутри одного метода нужен вспомогательный класс

это случаем не тот случай, когда ФП в джаву впихивают?

Я думаю, что разрабы языка явно умнее, чем многие в этом чате

+

и все таки в ООП надо работать с доменами, вся эта фпшнина лишняя

Тогда уж и без статиков, утилитных классов и прочего (см. Егора)

это случаем не тот случай, когда ФП в джаву впихивают?

вообще не тот

Не нравится, значит делай свой язык со своими правилами

Тогда уж и без статиков, утилитных классов и прочего (см. Егора)

да, но без фанатизма.

Тогда уж и без статиков, утилитных классов и прочего (см. Егора)

егор это парень который "я пишу на ооп, все остальные пишут говно"?

егор это парень который "я пишу на ооп, все остальные пишут говно"?

Екзакли!

мм, авторитет, да

мм, авторитет, да

ни разу, но умные мысли у него есть. ко всему надо подходить со здравой критикой

ни разу, но умные мысли у него есть. ко всему надо подходить со здравой критикой

К его словам в первую очередь xD

К его словам в первую очередь xD

я как раз про это и написал)

прочитал, переворил, покритиковал и взял что то для себя

Не нравится, значит делай свой язык со своими правилами

ты про что?

(на самом деле прочитал всего пол его статьи)

ты про что?

Про то, что всё что нужно в язык вводят, а то, что хотят пользователи это мало важно

И проход по мапе вполне очевидный и читабальный

И проход по мапе вполне очевидный и читабальный

причем тут проход по мапе? О_о

и  Pair в языке-то есть

Ну критиковали ведь map.entry

А не, я просто не всё прочитал

А в чем суть класса Pair?

Не так часто приходится его использовать

Да и он по факту не нужен

С точки зрения памяти будет одинаково

ну в шарпе есть out и ref

Это я знаю

Но это вместо указателей

если метод должен вернуть несколько значений которые не связанны логически

Шарп это не java

если метод должен вернуть несколько значений которые не связанны логически

Не делать значит такого

Либо это должен быть массив

Либо делай через переменные в самом классе

вот тут и начинается

out[0] out[1]

вообще не затрудняет понимание

ERROR: S client not available

Ну в шарпе это довольно удобно

И стиль там другой

Но это не обязательно

Можно сделать через отдельные методы

И сильно не пострадать

вообще многие делают так

для случаев когда лень создавать новый бесполезный класс враппера для 2х объектов

Класс можно создать, но если там будут только геттеры и сеттеры

Может опрос сделать. В вашей кодовой базе есть класс Pair?

Но как-то не особо это и важно

Может опрос сделать. В вашей кодовой базе есть класс Pair?

Го

Я не умею)

Я тоже

В ваших проектах присутствует класс Pair? public poll Да – 15 ??????? 65% @OlegUshakov, @SergKuznetsov, @timakden, @msamoylych, @volyx, @LEXXEI, @acmi831, @SneakyThrows, @nischebrod_buterbrod, @DEADMC, Raman, @awolfspb, @f_vorontsov, @Genusss, @Regis_SDA Нет – 8 ???? 35% Mikhail, Vladimir, @acyut, @mordog, @goncharovdv, @TearingManager, Roman, @lex_it ? 23 people voted so far.

Во, вышло

Но я думаю, что нужно бы это запинить

Но админов я не видел

Есть забавная либа javatuples - там и Pair есть, и Triplet, и даже Decade)

Дико, но ожидаемо

Нужен третий вариант, есть - из сторонних библиотек

Я фз как добавлять третий

Оно только два поддерживает

Есть забавная либа javatuples - там и Pair есть, и Triplet, и даже Decade)

есть забавная либа под названием scala, там есть Tulpe1, Tuple2 .. Tuple22

Можно просто вопрос поменять на "используете ли вы"

И учитывая что это pro.JVM - то нужен вариант "есть уже в языке"

Tuple в javax есть вроде

для случаев когда лень создавать новый бесполезный класс враппера для 2х объектов

Гуава, не?

Нужен третий вариант, есть - из сторонних библиотек

А вариант что в одном есть в другом нет?

Гуава, не?

Гуава в андроиде не канает)

Я думаю, что разрабы языка явно умнее, чем многие в этом чате

Какого языка-то? Scala, kotlin, groovy?

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

Гуава в андроиде не канает)

В андроиде pair из коробки идёт