-
Notifications
You must be signed in to change notification settings - Fork 603
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
suggestion: add cache
package
#4608
Comments
Looks like a special case of memoization (memoizing a nullary function), and IMO it'd be more useful to have a general
There's also currently a Stage-1 TC39 proposal for memoization which could be a good reference point. The proposal as it stands relies on tuples though, which are currently at Stage 2. |
Thanks for your Comment @lionel-rowe! The scope of this feature is just to allow lazy initialization / lazy code execution. See the Kotlin std where the inspo is coming from. Your large comment kinda shows how complex real memo is. Which maybe not beneficial when the proposal advances or as a first step going into the Memo topic for the Deno Std. The Lazy method is simple enough to not have any large drawbacks, as it's quite straight forward. if cache empty, run the function, cache the result, return the cache. |
Proposals at stage 1 typically take several years to get to stage 4 and achieve widespread implementation, and there's no guarantee they'll get there at all — quite often the committee fails to reach consensus on some sticking point and they get delayed indefinitely or withdrawn. The reason I mention memoization here is that I have a couple of use cases for it currently, and only the other day I was considering suggesting it for inclusion in I currently have an implementation of |
@iuioiua any enthusiasm for adding a I've also had a look at the Kotlin |
I can't speak from experience as I've almost never used such APIs. Given, I'd lean towards this being valuable. I'll defer to the opinions of others here. |
caching
package
+1 even though an implementation for this has to be opinionated. I think it's useful to have this in Std as it's a common need that has a non-trivial solution. Lodash also has However, I don't quite understand the difference between Also, consider naming the package "cache" instead of "caching". We have precedent for both, though: |
Yeah I had a look at lodash's, not a big fan of how it implements customization of the cache. If you wanted to use a parameterized class like the class LruCacheWithMaxSize100 extends LruCache {
constructor() {
super(100)
}
}
const OriginalCache = _.memoize.Cache
_.memoize.Cache = LruCacheWithMaxSize100
const fn = _.memoize((...args: any[]) => { /* ... */ })
_.memoize.Cache = OriginalCache
Probably not, my guess is that the difference between the two would rarely if ever make a difference in real-world scenarios. And it could always be added later as an enhancement to the
I'm not married to |
caching
packagecache
package
Sorry, yes, |
Thoughts on adding a |
Yes, please open a separate issue. I'd like to see more evidence of demand. |
Is your feature request related to a problem? Please describe.
Often in code there is a need to run something like lazy, like connecting to a database. Seen also in Kotlin
Describe the solution you'd like
i would like to have a function that gets executed once and returns the results always.
Describe alternatives you've considered
Doing it manually and more verbose.
Example Implementation
The text was updated successfully, but these errors were encountered: