J. S. Choi
J. S. Choi
@michaelficarra: It is observable if we expose the cache to the developer somehow. For example, we may allow the developer to supply a map-like cache argument. (See also [proposal-policy-map-set](https://github.com/js-choi/proposal-policy-map-set), which...
@michaelficarra: The more personally important use case for allowing custom caches is to allow the user to specify the memoization’s [cache replacement policy](https://en.wikipedia.org/wiki/Cache_replacement_policies). For example, I may want to specify...
https://github.com/js-choi/proposal-function-memo/issues/5#issuecomment-1083466911 reminded me that records/tuples cannot directly contain objects, so that goes out the window. Looks like we would have to use trees of Map-likes—or compositeKeys—after all. Or maybe there’s...
@michaelficarra: I agree. I would much prefer a flat one-level cache data structure with complex keys. I suppose we could still: 1. Use argument tuples as keys in the developer-supplied...
According to [composite keys’ explainer](https://github.com/tc39/proposal-richer-keys/tree/master/compositeKey), “at least one component must be a valid key that can be placed in a WeakMap”. Unless I am mistaken, this restriction would exclude them...
It is a good point that key customization is important, and that the tuple-based approach in https://github.com/tc39/proposal-function-memo/issues/4#issuecomment-1083552333 would not address even common use cases like option objects. It is also...
I certainly agree: we need a lot more specific use cases in the explainer. This ties with #7. I agree that I have seen memoization mostly used in algorithms, although...
@michaelficarra: If we used a WeakMap cache and `Object(x)`, where `x` is a primitive, then how would we efficiently look up results in the cache, since `Object(x) !== Object(x)`?
Yes, the error-caching question is a good one. We need to investigate what current libraries do here.
@waldemarhorwat: It does look like at least one `once` implementation ([lodash.once](https://github.com/lodash/lodash/blob/4.17.15/lodash.js#L10617); see also [lodash.before](https://github.com/lodash/lodash/blob/4.17.15/lodash.js#L10039)) releases its reference to the original callback after calling it for the first time. Matching this...