Perl has had this for 12 years or so, and Lisp way before that.<p><a href="http://perldoc.perl.org/Memoize.html" rel="nofollow">http://perldoc.perl.org/Memoize.html</a><p>I suggest you look into the design here. memoize() works on functions, which is a lot more useful than catching missing methods. That way, the library author can memoize functions, and so can the library user, if they are sure the function they want is pure (i.e. no side effects).<p>I see problems with allowing callers to memoize methods of an object. You're breaking encapsulation when the caller can suddenly decide how a method is to be cached. In principle, every method of an object depends on the object's private state, which could change at any time. So how are callers supposed to know what is and isn't cacheable? Or when to expire a cache?<p>Also, the average object has methods for writing and reading. It would be pretty silly to allow there to be cacheable writing methods. Again that suggests control over what is cacheable should be in the class.<p>That said, you've got a good idea here -- just figure out how we can give the class control over what is memoized. I am pretty sure this is doable; perhaps you have a private method _get_memoized_methods() that tells the inherited abstract class Memoizable what can be memoized. It can then make it appear as if $object->fastQuery() exists, when it's just a wrapped around the private method $object->slowQuery(). You can do this, I think, by catching missing methods with a __call function in Memoizable, and, I think, you can throw exactly the same exception as PHP would whenever a method that you don't want to mess with is called.