Oliver Steele

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.