# [RFC] Weak References - Thread: https://externals.io/message/54045 - Original archive: https://news-web.php.net/php.internals/54045 - Started by Hannes Landeholm on 2011-07-18T16:19:24+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54045 — Hannes Landeholm — 2011-07-18T16:19:24+00:00 URL: https://externals.io/message/54045#54045 Hello, This is the official RFC discussion thread for Weak References and an announcement of the RFC. Please read the RFC before replying: https://wiki.php.net/rfc/weakreferences In a nutshell: The RFC proposes adding a single class called "SplWeakRef" which provides the "Weak Reference" feature. This is the only change. Previous thread was here: http://news.php.net/php.internals/53963 I'm creating this new thread for several reasons. First of all I feel that the RFC is now somewhat complete and an announcement should be formally made with the [RFC] subject in accordance to the voting procedure. Also the other thread has more general discussion on internal reference counting and garbage collection. Please keep this thread on topic - specifically about Weak References and the RFC. If you plan on voting no to this feature, please reply to this thread so we can discuss your concerns. As I've previously stated, I hope that this feature can be released with PHP 5.4 since I need it for my own projects and open source framework. I don't think this is unreasonable since it's such a simple class and also non-controversial. It has been an established feature in many other major OOP languages for years. I will therefore initiate voting as soon as possible (In two weeks). Thanks Etienne Kneuss for creating the first version of the RFC and the patch and others for discussing it. ~Hannes --- ## #54052 — Adam Harvey — 2011-07-18T18:12:29+00:00 URL: https://externals.io/message/54045#54052 · In reply to: #54045 > In a nutshell: The RFC proposes adding a single class called "SplWeakRef" > which provides the "Weak Reference" feature. This is the only change. This may just be Monday morning fuzziness, or I've just missed something in the RFC, but is there a reason weak references would be limited solely to objects, rather than any variable that can be dealt with by-reference? Thanks, Adam --- ## #54055 — Hannes Landeholm — 2011-07-18T18:50:54+00:00 URL: https://externals.io/message/54045#54055 · In reply to: #54052 Weak references is an OOP concept. Scalar data types and arrays are not OOP-related so I don't think that would make sense. Variable references is not the same as object references. A variable reference is simply a variable that is connected with another variable (if you set one it will change the other). If two variables have the same object reference they are not connected, if you set one variable the other is still set to the initial object reference. Also, arays and strings have special memory handling - they use lazy copying so it's opaque if two equal arrays/strings refer to the same region of memory. It's unclear what construction/destruction even mean in that sense. An array might actually have been "constructed" by the compiler. A reference to an object instance is a "pointer" but a reference to a variable is not. http://us.php.net/manual/en/language.references.arent.php I hope that illustrates the difference. Do you have any special use case in mind? ~Hannes > > This may just be Monday morning fuzziness, or I've just missed something in > the RFC, but is there a reason weak references would be limited solely to > objects, rather than any variable that can be dealt with by-reference? > > Thanks, > > Adam --- ## #54056 — Adam Harvey — 2011-07-18T18:57:44+00:00 URL: https://externals.io/message/54045#54056 · In reply to: #54055 > Weak references is an OOP concept. Scalar data types and arrays are not OOP-related so I don't think that would make sense. Variable references is not the same as object references. A variable reference is simply a variable that is connected with another variable (if you set one it will change the other). If two variables have the same object reference they are not connected, if you set one variable the other is still set to the initial object reference. > > Also, arays and strings have special memory handling - they use lazy copying so it's opaque if two equal arrays/strings refer to the same region of memory. It's unclear what construction/destruction even mean in that sense. An array might actually have been "constructed" by the compiler. A reference to an object instance is a "pointer" but a reference to a variable is not. > > http://us.php.net/manual/en/language.references.arent.php > > I hope that illustrates the difference. > > Do you have any special use case in mind? Nothing in particular, and I understand the differences in memory and reference handling between objects and other variables within PHP. It just seemed like an inconsistency, and I was curious whether it was a design or technical decision. I guess the answer to that is "yes". :) Thanks, Adam --- ## #54057 — Hannes Landeholm — 2011-07-18T20:18:04+00:00 URL: https://externals.io/message/54045#54057 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. > 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 --- ## #54058 — Etienne Kneuss — 2011-07-18T20:59:55+00:00 URL: https://externals.io/message/54045#54058 · In reply to: #54052 Hi, > > > […] > > This may just be Monday morning fuzziness, or I've just missed something in > the RFC, but is there a reason weak references would be limited solely to > objects, rather than any variable that can be dealt with by-reference? Other kinds of variables does not allow us to define specific hooks like for objects. Implementing weak references (note that in this context reference != php reference, but object reference) for other types would require considerable changes to the engine, which we are trying to avoid here. In this case, for objects, the implementation remains quite simple, because objects allow such introspection already. Last but not least, it also makes little sense to do so from a design perspective, as other types do not provide the handle indirection that objects do. > > Thanks, > > Adam -- Etienne Kneuss http://www.colder.ch --- ## #54257 — Hannes Landeholm — 2011-07-30T23:42:59+00:00 URL: https://externals.io/message/54045#54257 · In reply to: #54058 Hello guys, I'd just like to remind you that I plan to initiate voting for this RFC on Monday (less than 2 days) so if you plan on voting no, please reply here asap so we can discuss your concerns. Thank you for your time, ~Hannes --- ## #54272 — Hannes Landeholm — 2011-08-01T01:59:16+00:00 URL: https://externals.io/message/54045#54272 · In reply to: #54257 Hi, I'd like to initiate voting on this RFC today since the minimum period of two weeks has now passed. Can someone with the right wiki powers/responsibilities start a vote and announce the [VOTE] on the mailing list? Thank you, ~Hannes --- ## #54273 — Stas Malyshev — 2011-08-01T02:28:51+00:00 URL: https://externals.io/message/54045#54273 · In reply to: #54272 Hi! > Hi, > > I'd like to initiate voting on this RFC today since the minimum period of > two weeks has now passed. Can someone with the right wiki > powers/responsibilities start a vote and announce the [VOTE] on the mailing > list? I think I'm missing some important point here. Why this can't be implemented as PECL extension? I looked at the patch and saw nothing that requires engine involvement. So why not just create a PECL extension? If people start using it and it gets popular, we can merge it to core as we did with many others. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54276 — Hannes Landeholm — 2011-08-01T07:30:37+00:00 URL: https://externals.io/message/54045#54276 · In reply to: #54273 Arguably the feature is already "popular". I have pointed this out many times before but many other major OO languages provides weak references natively. Read the introduction in the RFC. Pragmatically speaking (as a framework designer) you are unfortunately not so privileged on what PECL/PHP extensions people should use and have loaded or not. Many hosting providers does not give you the option to load your own extensions and does not change the default configuration. So you are really avoiding non standard features when designing generic applications/frameworks that should be usable by anyone. This means that the PECL extension popularity proves nothing. Implementing it as a PECL extension will most likely prevent people from using it. I wouldn't. Finally to fully support Weak References in the future it has too make some small adjustments to the GC so the collection event can actually be caught (see rfc/additional cleanup and __destruct()). That might also be reason to why it should be implemented directly. Etienne Kneuss should be able to answer this better. ~Hannes > Hi! > > I think I'm missing some important point here. Why this can't be > implemented as PECL extension? I looked at the patch and saw nothing that > requires engine involvement. So why not just create a PECL extension? If > people start using it and it gets popular, we can merge it to core as we did > with many others. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227