4 ms·
A Better Javascript Memoizer
- lsb 17y agoIt's not necessarily better. For example, you can't punch any new values into the cache.
- nathanwdavis 17y agoTowards the end of the article and in the comments there is some ideas for expiring a cache entry. This would allow for a specific life of the cached output and then make room for an updated version of the output.
- ellyagg 17y agoWhy is adding a property to a function "pollution"? Functions are objects and the sooner you learn it, the better. My objects have properties for whatever I need them to. I don't feel bad that I can define objects without tons of boilerplate and bookkeeping. It's one of JavaScript's charms.
- artlogic 17y agoIt's a neat approach, but I can anyone give explicit reasons as to why using a function instance variable is "bad"?
- arebop 17y agoGlobal data is bad; only the memoization code needs to access the cache; why expose the cache more broadly than that? More explicitly, one problem with overexposure is namespace collisions.
- artlogic 17y agoGlobal data can be bad, but a function instance variable isn't global - it's simply public. Using closures to simulate private variables has always seemed like overkill to me, but I tend to prefer Python's approach to private variables. Also, being able to manipulate the cache from outside the function could be helpful in certain cases where a full fledged cache object would be overkill. I do agree that namespace collision is certainly an issue, but it's traditionally resolved by mild name mangling (again, see Python). In my opinion, the advantages of a less clever (read easily understood) public implementation outweigh the disadvantages.