2006/1/24, James Edward Gray II <james / grayproductions.net>:

Going back to the original question which approach to favour...

> The primary difference between our two approaches is that Daniel's
> library is built to memoize individual objects, while mine is
> intended to link all instance method calls for a class of objects to
> a single cache.
>
> I wanted this behavior because I felt it would increase cache hits
> and make memoizing methods that much more worthwhile.  Daniel pointed
> out though that a finer grained control can be important, to avoid
> exhausting memory with the cache.  Luckily, Ruby's syntax makes it
> trivial to use my library to alter a unique object as well.

I may have missed something but from what I understand I see a
complete different problem: if you memoize for all objects of a class
then you have two options: either use only method name and args as key
(which I believe you do because you want better cache hits) *or* store
add something that identifies the instance (object id, the object
itself) which clearly would lead to cache hit ratios like in Daniel's
approach.

If you have a single cache for all (first alternative) you risk that
cached results are wrong because they may depend on individiual
object's state which you do not reflect in the cache. If you choose
the second approach you make things more complicated than necessary
(think of GC for example and how the cache gets notified if content is
invalidated etc.).

So, basically I prefer Daniel's simpler approach - especially since
you can achieve the same: just create an instance that contains all
code (either directly or by delegation) that is expected to be slow
(and thus should be memoized) and memoize on that class.

> My library also works for class/module methods and even top-level
> methods, though I will spare you those examples.
>
> The other difference between our libraries is that Daniel's supports
> using a file for persistent caching, while my library supports using
> a custom cache object.  That means that it's a little more work to
> cache to a file using mine, but you can do other kinds of caching as
> well.  Here's a file cache example:

I like the idea with a generalized cache.  Default is a hash but it
can be replaced by some file handling object that adhers to the same
interface (even multilel caching with a LRU cache in mem and the whole
cache on disk can be done... :-)

Kind regards

robert
--
Have a look: http://www.flickr.com/photos/fussel-foto/