ConcurrentHashMap/ConcurrentMap/Map.compute

[Joe Bowbeer]

I think that most if the initial users of the compute methods will already
be familiar with the 'compute' names. I am, as is Doug.
On Dec 14, 2012 10:02 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> We do not have explicit parallel versions of forEach for anything yet.
>>> Existing
>>> forEach methods are inherently sequential.
>>>
>>
>> But does any spec promise this?
>>
>
> Our mantra has been "no transparent parallelism."  So, I think it should
> promise this.  If you want parallel forEach you can do:
>
>   coll.parallel().forEach()
>
>  I still find the name "compute" very unsatisfying,
>>>
>>
>> As I mentioned, I initially didn't like these names at all.
>> Pasted here for convenience:
>>
>> V computeIfAbsent(K key, Function<? super K, ? extends V> f);
>> V computeIfPresent(K key, BiFunction<? super K, ? super V, ? extends V>
>> f);
>> V compute(K key, BiFunction<? super K, ? super V, ? extends V> f);
>> V merge(K key, V value, BiFunction<? super V, ? super V, ? extends V> f);
>>
>> Starting from scratch, I might call computeIfAbsent "establish".
>> (Three years ago, when considering a MapMaker-like j.u.c class,
>> I proposed several names along these lines but eventually gave up.)
>>
>> But given computeIfAbsent, the name computeIfPresent seems forced,
>> and then computeIfAbsentOrPresent==**compute seems forced. And if you
>> see the scheme laid out in this way, looks OK. Which is presumably
>> why all the CHMV8 users seem to like it.
>>
>
> What about recompute for compute, and recomputeIfPresent for
> computeIfPresent?  (The former has a slight weirdness about the first time,
> since you can't recompute something that isn't yet computed, but that
> weirdness seems much less than the unapproachability of compute. And as far
> as I can tell, no one has considered these names yet.
>
>