It may be confusing (to some, I guess) but it is consistent: the ThreadLocal subclass author has absolute control over how the value is presented to the user. Adding compute() or many of the other suggested variants will break that guarantee, which seems like kind of a big deal to me.
What about introducing a different thread local API that has more modern behavior? Maybe a new subclass of ThreadLocal? On Mon, Jun 18, 2018 at 5:28 PM Martin Buchholz <marti...@google.com> wrote: > > 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 > > -- - DML
