Re: Function caching...

> At 09:27 12/12/2000, Ron Chmara wrote: > >1. Function/result caching. Nobody's really suggested a reason why this > >_shouldn't_ > >happen, only posted issues about why we don't want to alter significant > >internal architecture portions to accomplish it. I like the idea, even > >though it > >has limited utility to me (I code my PHP differently). Implementation > >issues... > >well, see #3. > > There are *very* good reasons why it shouldn't happen. It's *extremely* > dangerous, and you have to have a very good idea of what you're doing (for > instance, you mustn't cache any function that depends on SQL or any other > external data source that may change). This is the sort of feature that > would be rated as 'prone to problems'. I'm not saying it mustn't exist, > I'm saying it shouldn't be advertised as a good thing to do, because it isn't. > > For this specific feature, there aren't any serious implementation issues, > by the way. Most of the work has been done in the output buffering layer. > I agree with everything Zeev just said, I'd just like to add in that where function caching has it's real benefit is when an expensive algorithm is called recursively and therefore the results of that algorithm can be cached in order to save time. This is a similair concept to MJD's (Mark Jason Dominus) Perl module Memoize.pm... -Sterling