-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add java.time.Duration overloads to Suppliers.memoizeWithExpiration() #3169
Comments
Funny you bring that up...I just had a need for that last week and have an internal CL out that adds the Should we accept the Should we accept and return Other ideas? |
@kluever Once this is done, I see no benefit in returning |
All APIs that accept a For this particular case: |
@kluever I would suggest hard-deprecating
After all, users don't need to "upgrade" to using |
I tend to agree with you. It is a little weird that we're mixing APIs that accept/return |
Can i pick this up? Will this work:
|
@nikhilbarar thanks for the offer, but I actually have a pending change out for this - we just need to work through the Guava Supplier vs. JDK Supplier issue. |
This CL contains part but not all of #3691 Fixes #3169 We'd considered this previously in cl/197933201 but gotten stuck on the question of whether to accept and/or return the `java.util.function` type. My claim is that we want an overload that is near-identical to the old one for ease of migration. Additionally, if we want to support `java.util.function.Supplier` in the future, then we're going to have to add an overload of the existing `memoize` method, and which point it would probably look _more_ weird if we had 2 overloads for `memoize` (and maybe `synchronizedSupplier`) but only a single `memoizeWithExpiration` method. RELNOTES=`base`: Added a `Duration` overload for `Suppliers.memoizeWithExpiration`. PiperOrigin-RevId: 597004403
This CL contains part but not all of #3691 Fixes #3169 We'd considered this previously in cl/197933201 but gotten stuck on the question of whether to accept and/or return the `java.util.function` type. My claim is that we want an overload that is near-identical to the old one for ease of migration. Additionally, if we want to support `java.util.function.Supplier` in the future, then we're going to have to add an overload of the existing `memoize` method, and which point it would probably look _more_ weird if we had 2 overloads for `memoize` (and maybe `synchronizedSupplier`) but only a single `memoizeWithExpiration` method. RELNOTES=`base`: Added a `Duration` overload for `Suppliers.memoizeWithExpiration`. PiperOrigin-RevId: 597004403
Suppliers.memoizeWithExpiration()
takes aTimeUnit
. Consider adding ajava.time.Duration
overload similar to what you did withCacheBuilder
.The text was updated successfully, but these errors were encountered: