Re: New Cache Class

Hi On 8/24/03 6:42 PM, David Rech wrote:

Hi,

Cache_Lite is roughly 300 LOC (without comments)

I'd use 108 lines without comments =) mine is smaller than yours, or what? ;)

Does any of the other packages offer such like an easy way to "assign" dynamic content to the cache?

nope, it doesn't (IIRC), but shouldn't be a big task to build that on top of any of the 2 caching classes and does absolutely not justify a whole new Cache Class IMHO

I've looked at PEAR Cache, and there are just things handling with expiration of sites and such things...or am I wrong with that? With my tiny package you can easily replace content such as usernames, session ids, the date shown on the page... :)

as can every templating system... and this is, what you basically did. Maybe handy, maybe not, but as said, can be built on top of existing code relatively easily.

For small- to midrange projects it has all you need. Maybe there are some things to change, but that's the way developing takes...making packages better and better ;-)

But you're not doing that right now. You're "inventing" new - very similar - packages instead of improving the existing ones.

Why need any SQL abstraction and such stuff, when you just need to assign your existing dynamic content (or the methods which generates it, for the ideal case) for caching reasons...

If you don't need SQL-abstraction or whatever fancy stuff PEAR::Cache provides, use Cache_Lite. It's more than good enough for xx% of most cases.

The implentation into an existing project is very easy, because you don't need to change the whole app to work with the cache. Just making little additions to the code and yo're done.

As it is with Cache and Cache_Lite. I still don't see any single reason to include your class. On the other hand, you would have my vote (if I'd vote....) for extending the existing classes and adding you're new ideas to it. I don't have a problem with that approach ;) chregu