This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: memoize() [caching is not agile] Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

More about caching, and memoize().

Hi. Yes, Memoize() is the sort of thing I was talking about. The problem with memoize is that it is not safe. What methods does your function call? do they depend on state?, does your function depend on state? - These are the sorts of things a functional language can flag automatically. Any function that does not change or depend on external state beyond its parameters is said to have 'no side effects'.

With the memoize() function, the programmer is being asked to specify if there is no side effects. This is exactly the sort of thing that we proggrammers get wrong all the time :)

I do agree that memoize() is an excellent short hand for situations when you do know if a function has no side effects, or if you can increase the scope of what is required to mark a return value again, ie: an instance variable or two. But, when you start second guessing things like this you end up with the scenario's I described in the main body of the blog.

Thanks for pointing memoize() out!, it's an interesting one.

Here's a good link to an implementation of memoize()