ConcurrentHashMap/ConcurrentMap/Map.compute

[Joe Bowbeer]

I slightly prefer computeIfPresent.

replaceIfPresent sounds redundant and its name does not imply computation.
 I'd like all the compute* methods to be listed together.



> Bikeshed: The name "replaceIfPresent" seems nicer than "computeIfPresent"
> and
> fits in with existing replace naming.
>
>> OK; none of the names of it are beautiful, but
>> either the analog-of-computeIfAbsent of of replace fine.
>> (I at first had this as just "replace",
>> but it can clash with the other form of replace in
>> weird cases where you have a map of keys to functions.)
>
>
>

On Wed, Dec 5, 2012 at 1:50 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/05/12 16:31, Brian Goetz wrote:
>
>> These look great to me!  This default method thing was a pretty good
>> idea!  :)
>>
>> Nit: uses Scala fat arrow instead of Java thin arrow in examples.
>>
>
> (Oops! A byproduct of talking about Scala in a course here yesterday :-)
>
>
>
>> Bikeshed: The name "replaceIfPresent" seems nicer than "computeIfPresent"
>> and
>> fits in with existing replace naming.
>>
>
> OK; none of the names of it are beautiful, but
> either the analog-of-computeIfAbsent of of replace fine.
> (I at first had this as just "replace",
> but it can clash with the other form of replace in
> weird cases where you have a map of keys to functions.)
>
>
>
>
>> For the value-oriented CHM methods (putIfAbsent, remove, replace), I
>> think it is
>> reasonable to move these up to Map with the obvious defaults, with no
>> promises
>> about atomicity, and adjust the ConcurrentMap spec to add a comment about
>> "unlike the Map versions, these are atomic."  The null rules get more
>> ad-hoc for
>> these, but can still be reasonably consistent with the lambda versions;
>> NPE on
>> any key being null.  For replace(K,V,null), we can treat that as
>> remove-if-present and replace(K,null) can be unconditional remove.
>> putIfAbsent(k, null) should be a no-op.  remove(key, null) becomes
>> "remove if
>> get() returns null", I guess.
>>
>
> I agree. Changing replace(K,null) would be a CHM spec change
> (now throws NPE) but an innocuous one since it makes an illegal
> case legal, and is good for sake of consistency.
>
> I'll flesh these out and resend sometime soon.
>
>
>
>> ObAndIWantAPony: I would also love to have Map.merge(otherMap,
>> mergeLambda)
>> whose default uses your merge below, but for which you could define a
>> better
>> override in Map implementations that offer a better than element-wise
>> merge.
>>
>>
> Well, you have the pony, but it's not in your favorite color:
> It's easy via the CHM bulk ops. (And was once a listed example
> but somehow I clobbered it. I'll put it back in.)
> It's not in any interface now that we don't have MapStreams.
> And probably not a great idea to add at Map level in case
> the need for something like MapStream arises again.
>
>
>
> -Doug
>
>
>