Как стать автором
Обновить

Комментарии 6

Спасибо огромное, немного обескуражен после прочтения.

Проблема на самом деле в смешивании побочных эффектов с чистым кодом
Большое спасибо что поделились опытом!
Самое простое решение — тупо не использовать эти методы
По названию статьи я подумал, что самое простое — это читать доку =( (шуточное)

заметьте, тут на поверхностный взгляд все «иммутабельно»
AtomicInteger, иммутабельно… Для того чтоб оно было иммутабельным, надо вместо чистого Атомика изобразить какой-то эффект с сохранением прозрачности. Аля Ref или MVar из котов/моникса.

Имхо, проблем две. Согласен, что модель вычисления должна быть одна для двух методов. Только в текущем Map (и его дефолтной реализации) map должен стать ленивым. И тут вторая проблема, что есть имплементации, которые строгие, а разделения на уровне типов нет.

К вашему удовольствию принято решение в 2.13 задепрекейтить mapValue (очень пикантно, для тех кто включает опцию "-deprecation"), а в будущем сделать строгой. Т.е. исправят лишь одну проблему.

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


А про ленивость map — вы имеете в виду такую же ленивость, как в mapValues, или с мемоизацией? Насчет того, что разделять их на уровне типов — полностью согласен.

Вместо map(identity) можно также сделать view.force:


m.mapValues(x => y).view.force

Разницы принципиально никакой, но меньше скобок :) а вообще, в большинстве проектов у меня есть extension-метод mapValuesEager который делает то что нужно.


Кроме того, вроде как в новой библиотеке коллекций в 2.13 это исправлено. В целом, конечно, это весьма неприятный подводный камень.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий