While I don't mind object masturbation, this is a little excessive.
But what concerns me most is that the purge operation (to expire objects which are too old) is O(n). Worse, purge is conditionally invoked (via 3 layers of indirection, mind you) on all get calls! Do you see how fucked this is? A cache retrieval operation should not be O(n).
My caching module for LiveJournal, though not as abstract as the Cache::Cache family, at least keeps data structures around to be able to efficiently clean itself.
From what I can tell, the problem with Cache::Cache is that its "Backend" abstraction needs to know how to purge itself.
Now--- a dilemna: do I steal the shared memory bits I want from Cache::Cache, or help them fix their inefficiencies? Unfortunately, the state of shared memory on Linux is pathetic. Stupid low limits. They're probably tweakable though... need to learn.
The CREDITS file for Cache::Cache lists 31 people. This is good... it means the maintainer takes patches. But have none of those 31 people noticed the purging operation sucks? I'd like to think I'm really smart, but perhaps I'm just stupid and am missing something. Anybody know that code? It's small... somebody else should go audit it and tell me if I'm on crack or not.
Update: Mailed the project maintainer, asking if I'm reading it right, and offering help fixing it if needed.
