On 17 July 2011 12:38, Ferenc Kovacs <tyr...@gmail.com> wrote: > > Hannes, now you should have karma for the rfc namespace, so you can > now extend the article with your suggestions.
Great, I'll start contributing ASAP. What's the next step after the RFC is complete? Testing? Voting? On 17 July 2011 15:04, Lars Schultz <lars.schu...@toolpark.com> wrote: > I too would welcome a solution to this problem, I've run into it several > times already and always had to use a semi-satisfactory solution. I hadn't > heard about weak-references before, and I generally like the concept. What I > am not so sure is wether this makes everything alot more complicated for > users who do not know/care about the problem or the solution. Of course the > impact on those users depends on the actual solution. > If you are writing code that caches objects/relations and that caching has a significant impact on memory usage, you need to care about memory allocation/management per definition. So then you have to learn how OOP memory managment works (which should be obligatory anyway if you want to call yourself a OOP-developer IMO). A common argument to why programmers should not start with a garbage collected language is that it prevents them from understanding memory allocation concepts. > I came at the problem from a different angle and came to a different > solution: If I could get the refcount on a certain object, and kept the > object stored centrally in one list, I'd know that if the refcount is down > to 1 (or some other constant) that the object ist not in use anymore. I > believe that this would be quite a simple PHP addition...a simple function > called: get_ref_count() or something and as I remember, that value is always > stored in the zval... > > The only other thing that would help would be a callback (or callable) > which is triggered by PHP reaching a certain memory-limit, absolute or > relative. Then I could clean up memory according to my own business-logic... > > This way, PHP would not feature something totally new, but one could still > solve the problem with some work. > > Do I make any sense at all? Am I missing the point? Anyway, this is an > interesting problem. > > Cheers. > Lars It would probably be simple to implement such functionality. However this would be bad design since it would violate responsibility isolation. PHP should expose as little internal stuff to the userland as possible - unless there are a clear use case for it, and even then it might be a bad idea because it could cause BC breaks in future updates. If you write code that depend on reference counts or memory usage - you're doing something wrong. You either need data or you don't. If you need data you reference it. If you don't reference it the GC will deallocate it. A fundamental part of OOP is designing your program so you never reference stuff you don't need. Weak references solve the special case where you need the reference for as long as you need the data it references (as long as there are strong references for it). You should have a clear reference graph in your application - there is no magic solution to good object oriented design. The only scenario I could imagine where you could "free memory" spontaneously on demand (when the arbitrary OOM limit is reached) - is if that would be cached data. Caching is a very complicated subject that is not directly related to weak references. Start a separate thread about it and present clear use cases if you have anything special in mind. For example, I need weak references to store a table of "back references" between objects for later reference (depends on how you use the objects). If A references B i also need a weak reference from B to A so if B should be replaced with a C object I need the weak reference from B to A to know that A should be updated to point to C instead (if A still exists). This is not related to caching. ~Hannes
