Am 04.08.2011 09:17, schrieb Stas Malyshev:
I'm sorry but you putting forth contradictory requirements here - you want to keep the objects (to avoid "expensively reconstructing" them) and you don't want to keep them (memory problems). You'll have to give up one of these requirements. As I see, you gave up the caching requirement and you clean up objects when memory is tight. As long as you don't need more objects than you have memory you should be fine.
As long as memory is infinite I'd be fine. It's not contradictory at all. I have to balance performance gain (keeping objects in memory) and memory usage (keeping too many objects out of memory).
You should control your code so that "somewhere else" does not keep extra references. As well as you'd have to control you code if you use weak refs, otherwise extra references would still keep objects alive - or you'd have to rewrite your code and control it so that is always uses weak refs and always checks that the ref is alive.
Not true. With WeakReferences, objects would be cleaned from memory as soon as my cache-list is the only place left still referencing it and the GC is run. Even better would be SoftReferences, which would only be cleaned when there is no memory left.
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.
I did not mean to defend WeakReferences, I just meant to give a valid use case. Your saying that I shouldn't do it doesn't help much.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
