yes, the proposed new methods would use nulls differently. The original get() behavior of creating a mapping was a mistake, inconsistent with Map. Yes, it will cause confusion. But it's already confusing.
On Mon, Jun 18, 2018 at 1:45 PM, David Lloyd <david.ll...@redhat.com> wrote: > On Mon, Jun 18, 2018 at 12:53 PM, Martin Buchholz <marti...@google.com> > wrote: > > On Mon, Jun 18, 2018 at 10:21 AM, Tony Printezis <tprinte...@twitter.com > > > > wrote: > > > >> Martin, > >> > >> You are forgiven. :-) > >> > >> So, the (valid, I think) issue with getIfPresent(), as originally > proposed > >> by Peter, was that if get() was overridden in the subclass to somehow > >> transform the returned value, getIfPresent() wouldn’t apply the same > >> transformation. > >> > >> Doesn’t your compute() method have essentially the same issue? Apart > from > >> that, I personally like this proposal as I agree: one look-up is always > >> better than two. > >> > >> > > A non-prototype implementation would delegate compute into ThreadLocalMap > > itself, where there is no risk of overriding. > > I don't think overriding is the risk; the risk would be compute* > behaving inconsistently with regards to an overridden get*. > > > -- > - DML >
