This post was mentioned on Twitter by major_code: http://tinyurl.com/cwomvm
A Better Javascript Memoizer | Unscriptable.com…

    var arity = func.arity || func.length;
    return memoizeArg(arity ? arity - 1 : 0);

-m

On the surface, Nicolas’ implementation looks good, but it’s not robust. Here’s why:

1. It adds properties to the function instance, f.
2. args.toString() is not guaranteed to be unique for all combinations of arguments.

Regarding the first point, any general-purpose function should avoid interfering with other code as much as possible. By assigning properties to the function instance, you have limited the calling code from using a similarly-named property on the function instance. This may seem like a minor point, but if all general-purpose functions worked this way, we’d eventually encounter conflicts — and this would result in some really nasty debugging sessions.

The second point is much more important. All Javascript property names must be strings, so the array is serialized to a string when it is used as a property name (f.memoized[args]). In Javascript, Arrays serialze to a CSV-like representation. For example, [1, 2, 3, 'foo'] will serialize to “1,2,3,foo”. This becomes a problem when objects are introduced — or even strings containing commas. Here’s what you’d get when you pass the following arguments:

[1, 'commas,are,in,here', {foo: 'bar'}] ⇒ “1,commas,are,in,here,[object Object]”

Unfortunately, the following arguments yield the same exact property name when serialized:

[1, 'commas', 'are', 'in', 'here', {prop: 'val'}] ⇒ “1,commas,are,in,here,[object Object]“

function memoize(f) {
  return function () {
      var args = Array.prototype.slice.call(arguments);
      f.memoized = f.memoized || {};
      return (args in f.memoized) ?
        f.memoized[args] :
        f.memoized[args] = f.apply(this, args);
  };
}

Courtesy of http://blog.thejit.org/

function() {
// some heavy function call/logic
}.property(’myName’).cacheable()

The .property() call ensures that if ‘myName’ changes, the cache invalidates. Also, there is an external call for expiring cache if needed…

Pretty neat, huh?

I just realized my untested code above has some mistakes…not surprising. Delete the line starting “var created” and change age.getSeconds()-maxage to expires.getSeconds()+maxage.

I originally decided to stay away from joining the serialized params because of the difficulty in choosing the join separator string. Yours looks pretty darn safe, imho, but there is still a minute chance that there could be ambiguities (false positives) in the cache caused when the parameters contain the join separator string.

My goal was to see if I could find a method that worked 100% of the time. I didn’t quite achieve my goal*, but I think that I got 0.00001% further because I eliminated the join ambiguities.

* Objects serialize to “[Object object]“. Doh! See kangax’s note on this memoization implementation: http://blog.thejit.org/2008/09/05/memoization-in-javascript/

Thanks for the feedback!

So, here’s a question: should the unmemoize feature forget the cached results at a strict future time (exactly at the designated expiration) or should it only forget at the next convenient time (some time after expiration)?

More specifically:

setTimeout(unmemoize, expiryPeriod); // strict time

or

if(new Date() > expiryDate) unmemoize(); // this is in the memoize method

Using a setTimeout will enforce a strict expiry time (assuming that the UI thread is not too busy). Otherwise, we can just check for expired cache entries when we’re adding new ones. This would allow us to prioritize as you mentioned. However, it seems like a lot more code / effort / memory.

Thoughts?