Comments 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 это исправлено. В целом, конечно, это весьма неприятный подводный камень.
Читаете ли вы Scaladoc для «очевидных» методов коллекций? Или почему лениться не всегда хорошо