Hi, Yes, I'm also interested in caching - It's a very interesting subject... borderline philosophical. When you are caching model instances in a database object relation layer you could clearly benefit from implementing some kind of caching mechanism that retains object even though it's unclear whether they actually need to be used (because you can't look into the future and known if the web application will select this ID again). I think it's bad design though to cache everything you can lay your hands on - memory usage is important. Also, database drivers and servers supply internal query caching. The programmer can achieve memory optimization caching by putting objects in a static variable if he knows he will need those objects later if the framework supplies internal weak-referencing. Trying to achieve this automatically with statistics and guessing would obviously not be as good a solution. But I stand by that "weak references" is not designed to solve this problem since it achieves the opposite - it removes caching - and it also solves other problems in other domains.
If I was really looking for a solution to this caching problem I would instead suggest an RFC that supplied a cache where you could put objects in a "recycle bin" state instead with different priority levels when destructing. The GC would then be allowed to make intelligent decisions on whether to allocate more OS memory or deallocate objects in the recycle bin pool depending on total PHP memory usage, total system memory and object recycle bin priorities. A userland programmer could also be allowed to "restore" objects from the recycle bin on demand. But that would be a completely separate RFC. Feel free to make a draft if you like. ~Hannes And yes, my main concern is to keep it simple so SplWeakRef could be implemented as quickly as possible. On 18 July 2011 21:42, Lars Schultz <lars.schu...@toolpark.com> wrote: > Hi Hannes, > > I think I like it after all;) What I don't understand is why you insist on > WeakReferences not being about caching, when your first usecase clearly is > at least related to caching. When mapping a DB-Record on a PHP-Object > on-demand and then keeping it instead of recreating it every time you need > it...of course you can argue it's not about caching because you'll be > dropping it as soon as you're not using it anymore...but isn't that a > deficiency rather than a different mechanism? As I've read in your quoted > article SoftReferences are used for that kind of stuff...and I'd really be > interested in that. > > But I guess your main concern is to keep it simple to make sure that it > gets accepted into 5.4?... > > Thanks for the RFC and the proposal...it seems like a useful feature to me > now. > > Cheers. > Lars > >
