hi,
On Sun, Jul 17, 2011 at 5:40 PM, Hannes Landeholm <landeh...@gmail.com> wrote: > 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? See https://wiki.php.net/rfc/voting So 1st discussing then 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 > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
