-
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 Duration and Supplier<Duration> overloads for Supplier#memoizeWithExpiration #3691
Add Duration and Supplier<Duration> overloads for Supplier#memoizeWithExpiration #3691
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
@googlebot I signed it! |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Hi @mfboulos, welcome to Guava. :) I think it's worth mentioning that it's unlikely this PR will be merged, because the Guava team prefer to do API reviews internally (which is apparently the hard part) and then write the code themselves to match whatever API they've agreed on. See the contribution guidelines for more information. |
That being said, I'm sure that this code would be a great start for @chriskilding's needs, who opened #3688, if you're happy for them to take the code as-is. :) |
FWIW, we have a copy of this in our (still internal) |
Understandable! My intuition was to put this PR in there just to have the code handy for you guys, but I understand there's more discussion behind it since it's essentially an extension to the existing API. |
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
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: 597280125
We added the |
Directly addresses #3688
I don't want to step on any toes since I saw that
long, TimeUnit
overloads are in the cards for several classes, but I also see the use in aDuration
supplier, so I went and wrote this up real quick so we can at least have it in the works.One thing I noticed while writing this is that
com.google.common.util.concurrent.Internal#toNanosSaturated
is package-scoped internal, but the only method in there is applicable to all legacy API's that require along, TimeUnit
, and there are several scattered inbase
,cache
, andcollect
undercom.google.common
. It might be worth considering gauging the need for it to public-scoped, if at some point the human race figures out how to prolong life indefinitely.Also first contribution here, hope all looks good :)