Languages of the real and artificial - Latest Comments in One-Line JavaScript Memoization

Re: One-Line JavaScript Memoization

Cheap Airsoft Electric Guns — Sun, 10 Aug 2008 16:20:56 -0000

Looks like it would work to me. Remember there are more than one way to skin a cat.

Re: One-Line JavaScript Memoization

playBunny — Sun, 20 Jul 2008 06:10:34 -0000

Why create a closure when you can just create a plain old function? It looks as simple as it is. No need to complicate things by calling the new function either.

Bezier.prototype.getLength = function() {
var length = ... // expensive computation
this.getLength = new Function ("return " + length);
return length;
}

Re: One-Line JavaScript Memoization

Timed Memoization — Sun, 06 Jan 2008 16:01:05 -0000

[...] One-Line JavaScript Memoization by Oliver Steele [...]

Re: One-Line JavaScript Memoization

osteele — Wed, 15 Aug 2007 12:42:19 -0000

Atany: thanks for the catch; 'tis done.

Re: One-Line JavaScript Memoization

Links of the day « Geeks in th — Mon, 21 May 2007 06:34:18 -0000

[...] One line memoization in javascript [...]

Re: One-Line JavaScript Memoization

Daily misery » Blog Archive » — Thu, 17 May 2007 22:31:24 -0000

[...] One-Line JavaScript Memoization at Oliver Steele [...]

Re: One-Line JavaScript Memoization

atany — Thu, 17 May 2007 20:04:26 -0000

Great article!

Could you please correct shortened memoizeConstantMethod to define local 'value' variable :)

The current version does not work correctly when called more then once for different methods.

Re: One-Line JavaScript Memoization

Bas Wenneker — Thu, 17 May 2007 15:47:49 -0000

Very cool technique, I wrote something like this in java some time ago, never thought about a javascript implementation. Great content you have on your blog! Thanks

Re: One-Line JavaScript Memoization

Ryan Johnson — Thu, 17 May 2007 15:10:10 -0000

Great stuff! I think you would enjoy this as well:

http://www.cs.cityu.edu.hk/...

This strikes me as something I might actually use in a number of practical cases though. Thanks for going into such detail, great explanations.

Re: One-Line JavaScript Memoization

ben lowery » Thursday — Fri, 27 Apr 2007 00:21:03 -0000

[...] For a “simple” language, Javascript is amazingly deep. Learning how to use a language with closures and runtime function generation just takes a shift in thinking from anything else I’ve done. The whole concept of memoization is just amazing. I think I’ve fallen off the strong-typing bandwagon. Oh if Bart could see me now… [...]

Re: One-Line JavaScript Memoization

Steffen — Mon, 22 Jan 2007 17:00:24 -0000

Just as a sidenote: Trying to subscribe to any of the feeds, be it rss or atom, gives a 500.

Re: One-Line JavaScript Memoization

Peter Williams » JavaScript Is — Mon, 28 Aug 2006 02:42:46 -0000

[...] While reading Oliver Steele’s article on JavaScript Memoization this bit jumped out at me. [...]

Re: One-Line JavaScript Memoization

P T Withington — Wed, 03 May 2006 11:23:35 -0000

Inner functions should only need to capture their free references. Are you just saying that most Javascript VM's are too simplistic, so they capture the entire scope chain? Bleah.

Re: One-Line JavaScript Memoization

developers.org.ua » Blog Archi — Fri, 21 Apr 2006 04:55:29 -0000

[...] One-Line JavaScript Memoization — JavaScript woodoo [...]

Re: One-Line JavaScript Memoization

Victor Laszlo — Wed, 19 Apr 2006 03:40:21 -0000

Nice article oliver. I have to say that this restriction:
> The inner function captures the variables from the outer function.

makes me a little suspicious of the fancier solutions you present. It's true that the memoization is caught up in the domain logic, but I have needed to do this rarely enough that it hasn't really bothered me. I'm more wary of memory leaks or ineffeciencies in the underlying runtime when using closures than bugs caused by rewriting a little code to test for the presence of a stored value.

Also, here's another take on your memoization routine that uses arguments.callee instead of closures.

function assignMemoizable( object, func , name ){
var f = function (){
if stored value exists
return from cache
else
return arguments.callee.originalFunction.apply( this , arguments );
}
f.originalFunction = func;
object.prototype[ name ] = f;
}

That seems like it would work too, no?

Re: One-Line JavaScript Memoization

dvb — Wed, 19 Apr 2006 03:01:14 -0000

First -- I have been very much enjoying your blog. Very thought provoking and inspiring! As ever, your approach is simultaneously academic and practical.

This article taught me a few new words (nullary, memoize) which will come in handy, and a few more of JavaScript's subtleties.

So, memoization. I like it. But I'm just a simple engineer unconcerned with language theory, and more concerned with getting stuff to work good, and stuff. Keith Gaughan's solution -- appending .memoize() -- onto a function certainly seems the least intrusive and tidy. And, agreed, managing multiple files and dependencies on a server is annoying. One solution for that would be to introduce a build-step to the development, resulting in a single file. Yeah... Edit, make, test. It's not the craziest flow in the world, though it is one more darned thing.

Reassigning the function to "return length" is appealing but troubling. It's an opaque state, it's self-modifying code, oh, it troubles me. And even more so for the self-neutralizing "Thing.noFun = function(){};"!

While these strategies are interesting, I'm always concerned that my code may be maintained by cave men, or myself late on a Sunday. These dynamic features are, obviously, a lot of fun... but I must confess: I'll opt for the first naive "Thag not compute Bezier length twice if Thag already have Bezier length! Ha!" solution: function bezierLength() { compute if needed, return }". Easy peasy.

Re: One-Line JavaScript Memoization

Johan SundstrÃ¶m — Tue, 18 Apr 2006 05:14:33 -0000

Nice technique and proposed idiom. (I also loved the Why combinator pun. :-)