Open OndrejSpanel opened 7 months ago
The mapValues has the same promise in its deprecation and suffers the same performance issue. I did not need it yet, but I guess it should be added for completeness:
Use .view.mapValues(f). A future version will include a strict version of this method (for now, .view.mapValues(f).toMap).
Note that @OndrejSpanel you don't want the strict version IIUC, since that is what m.view.filterKeys(p).toMap
does; that strict version is mostly to reduce the boilerplate.
Rather, it seems you want a lazy version that behaves like m.view.filterKeys
but without loosing the Map
type.
Rather, it seems you want a lazy version that behaves like
m.view.filterKeys
but without loosing theMap
type.
Is that even possible? And if it is, I find it hard to believe any lazy solution would work well when chained multiple times, which is what my use case really is - like (((map.filterKeys(p1) ++ aSeq1).filterKeys(p2) ++ aSeq2) ... .filterKeys(pN)) ++ aSeqN
Maybe what I really want is my workaround and I do not need this API at all. Maybe it is not possible to be more efficient?
Map.filterKeys is deprecated as the moment. Its deprecation message says:
The suggested
.view.filterKeys(p).toMap
is not very efficient, it rebuilds the whole map. Could a strict version be added as promised by the deprecation warning?Following workaround provides a more efficient solution for those interested:
See also https://stackoverflow.com/q/78354572/16673