ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)
Brian Goetz brian.goetz at oracle.com
Fri Dec 7 08:50:49 PST 2012
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Extraneous {@code fragment in compute().
I think the semantics of compute can be explained better; people will likely confuse it with computeIfAbsent. There's an aspect of reduction going on here; the remapping function is like a reducer under the "null means nothing there" semantics. It would be great if the name could suggest this; barring that the docs should explain it. Only when users get to the "create or append" example will they get it.
Seems like you didn't yet fold in the bits about scope of atomicity? Will that go in CM docs?
What do you mean by "possibly iterative equivalent of"?
On 12/7/2012 11:16 AM, Doug Lea wrote:
On 12/07/12 09:51, Doug Lea wrote:
Basic idea: defaults for function-accepting Map methods are solely in terms of the 4 CM methods, which are in turn non-atomic for non-CM.... See update at: http://gee.cs.oswego.edu/dl/wwwtmp/apis/Map.html These probably now take more effort for users to understand, but otherwise seem pretty good to me. Any complaints? (I reordered some of the decls so that they would flow a little better for the 5% (if that) of users who ever read the Javadocs sequentially.) -Doug
- Previous message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Next message: ConcurrentHashMap/ConcurrentMap/Map.compute
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list