On Thu, Aug 4, 2011 at 6:35 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > On 8/4/11 5:34 AM, Lars Schultz wrote: >>> >>> Do not keep object references, keep object IDs. This would make your >>> code a bit more verbose and a bit slower, but weak refs would >>> essentially do the same anyway. >> >> This is like saying: do not use objects at all and use the DB for >> storage. verbosity and slowness is something I'd like to prevent. > > No, it's not even remotely like that. Using one intermediary function and > doing the DB call is orders of magnitude apart. You asked how you can solve > the problem, I showed you how. You can claim you don't like the solution, > that's fine, everybody has his own taste. But you can't claim there's no > other solution.
maybe it's just me, but I not fully understand your solution. "I'm not sure I understand why you need week refs there - can't you just always use $prodDb->getProduct(1) and when you don't need it anymore just do $prodDb->drop(1)? Or let it drop it whenever it wants to?" "Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway." from that, my guess is that you propose that nobody should hold a reference for the product, but always use the returned object from getProduct() on the fly. you also suggest that ProductDatabase should also remove the cached object when appropriate. did I get interpreted your solution correctly? I have some problems with this approach: - you cannot guarantee/force the contract that the result of the getProduct cannot be stored. - in a loosely coupled system, it is hard to tell when "you don't need it anymore". as you and Lars both mentioned we only care about freeing the cache, because we have memory constraint. Lars mentioned that currently he manually checks the memory usage, and free the cache if needed: http://www.mail-archive.com/internals@lists.php.net/msg52423.html of course one could also write some algorithm, which removes records from the cache either randomly, or as Jonathan suggestion doing something like LRU/MRU. with Weak References, you shouldn't care about that, the gc would do it for your, albeit in a less sophisticated way: if the gc root buffer is full, then free every item which isn't used at that time. and of course you can combine the WeakRefs and some cache algorithm as Jan did in his blogpost. (good article btw. and also good to see that Benjamin Eberlei from the Doctrine project looking into the possible use cases for them) so as I see you didn't really addressed the proposed use-case of the Weak References, just stated what everybody is aware of: one can cache and free objects "manually" without the need of Weak References. and while that is true, I still think that this could be a great asset for creating high quality components. as we agreed that this won't be considered for inclusion to the core but released as a pecl extension, I think that we should update the RFC accordingly and close the vote. we will see what happens when people start using and experimenting with it. btw. it was suggested before, but I really think, that it would be a good idea to have a register_ function which would allow you to pass a callable, which will be called when the memory usage reaches a given value. that would make a good addition to resolve some of use cases mentioned in this thread. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
