SM
Ну вроде список пар в мапу превратить не должно быть проблемой, нет?
Size: a a a
2020 April 13
AN
Associate тогда. Или mapOf на лист пар
D
Associate тогда. Или mapOf на лист пар
после zip?
D
Ну вроде список пар в мапу превратить не должно быть проблемой, нет?
попробую, вроде не должно =)
I
toMap же!
SM
после zip?
Ага
AN
toMap же!
ну там куча всего
AN
Но вообще когда в мапе ключами работают произвольные побъекты, с большой вероятностью что-то пошло не так
D
Но вообще когда в мапе ключами работают произвольные побъекты, с большой вероятностью что-то пошло не так
что в твоем понимании произвольные?
D
не вижу ничего плохого использовать в качестве ключа data class
D
Был вариант использовать
Map<fieldId, Pair<ClassA, ClassB>> но подумал, что это еще хуже.
А так да, с архитектурой тут налажали.
Map<fieldId, Pair<ClassA, ClassB>> но подумал, что это еще хуже.
А так да, с архитектурой тут налажали.
SM
Был вариант использовать
Map<fieldId, Pair<ClassA, ClassB>> но подумал, что это еще хуже.
А так да, с архитектурой тут налажали.
Map<fieldId, Pair<ClassA, ClassB>> но подумал, что это еще хуже.
А так да, с архитектурой тут налажали.
Ну выглядит то даже и лучше наверное. Есть явное упоминание ключа 🙂
D
Почитал, zip не подходит. Он тупо складывает. А мне надо по predicate ( classA.fieldId == classB.fieldId )
D
Ну выглядит то даже и лучше наверное. Есть явное упоминание ключа 🙂
не нравится, что fieldId упоминается 3 раз. В качестве ключа, в качестве значения в ClassA, в качестве значения в ClassB
SM
не нравится, что fieldId упоминается 3 раз. В качестве ключа, в качестве значения в ClassA, в качестве значения в ClassB
Зато есть понимание того, как ClassA и ClassB оказались в одной корзине 🙂
D
SM
Почитал, zip не подходит. Он тупо складывает. А мне надо по predicate ( classA.fieldId == classB.fieldId )
Ну тогда попробуй сразу
associate с поиском пары по коллекции с ClassB или associateBy с поиском ключа по коллекции с ClassA.D
Спасибо, буду пробовать
MZ
Если производительность/память важна, а эта операция в вашем коде случается часто, то лучше всего сделать своих эффективных extension. Всякие там join, uniqueJoin, leftJoin ... Пишутся они относительно быстро, а написать хуже чем в kotlin runtime вряд ли у вас получится.
RI
Maxim Zinchenko
Если производительность/память важна, а эта операция в вашем коде случается часто, то лучше всего сделать своих эффективных extension. Всякие там join, uniqueJoin, leftJoin ... Пишутся они относительно быстро, а написать хуже чем в kotlin runtime вряд ли у вас получится.
Нужно тогда подкрепить кодом и продемонстрировать, желательно с jmh и сравнение с sequence на разных входных данных