# [VOTE] Weak References - Thread: https://externals.io/message/54277 - Original archive: https://news-web.php.net/php.internals/54277 - Started by Hannes Landeholm on 2011-08-01T16:46:05+00:00 - Messages: 69 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/54277.md?page=2 - 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 --- ## #54277 — Hannes Landeholm — 2011-08-01T16:46:05+00:00 URL: https://externals.io/message/54277#54277 Hello, Voting is now open for the weak references RFC. The RFC and patch can be found here: https://wiki.php.net/rfc/weakreferences You can vote here: https://wiki.php.net/rfc/weakreferences/vote I don't seem to be able to vote myself and I'm not sure if that's an error or not. Regards, Hannes Landeholm --- ## #54278 — guilhermeblanco@gmail.com — 2011-08-01T18:27:11+00:00 URL: https://externals.io/message/54277#54278 · In reply to: #54277 Hi, I like this idea. But I'd like to ask something; maybe someone could please correct the Example section of RFC? Unfortunately, I cannot understand how it could work on "else" conditional block, because $obj is undefined. Cheers, > Hello, > > Voting is now open for the weak references RFC. > > The RFC and patch can be found here: > https://wiki.php.net/rfc/weakreferences > > You can vote here: > https://wiki.php.net/rfc/weakreferences/vote > > I don't seem to be able to vote myself and I'm not sure if that's an > error or not. > > Regards, > > Hannes Landeholm > > -- > > > > -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #54279 — Hannes Landeholm — 2011-08-01T18:36:00+00:00 URL: https://externals.io/message/54277#54279 · In reply to: #54278 Sorry that this was unclear, $obj is defined in the comment that says "// compute $obj" Imagine a SQL query there or otherwise code that constructs $obj from an external data source. Regards, Hannes On 1 August 2011 20:27, guilhermeblanco@gmail.com wrote: > Hi, > > I like this idea. But I'd like to ask something; maybe someone could > please correct the Example section of RFC? > Unfortunately, I cannot understand how it could work on "else" > conditional block, because $obj is undefined. > > Cheers, > > > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #54280 — Hannes Landeholm — 2011-08-01T18:50:17+00:00 URL: https://externals.io/message/54277#54280 · In reply to: #54278 Hello, I would just like to remind you that the voting will take place for 7 more days so there are still time to discuss your concerns. If you find something confusing or have objections I would be very interested in hearing them and discussing that _before_ you vote as I have reminded you twice now during the 2 week discussion period. Remember that people want this feature, so the least you can do is explain your objections before you vote no. Silently burying feature requests does not help anybody. aharvey: I'm surprised you voted no since you seemed content with the answers you got earlier. Do you have some special objection in mind? Cheers, ~Hannes --- ## #54281 — Pierre Joye — 2011-08-01T19:16:56+00:00 URL: https://externals.io/message/54277#54281 · In reply to: #54277 hi, You have to start a new thread to begin a vote, see the voting RFC. So everyone will see it. However, I feel like it is premature to vote on that one. For one, I'm not convinced by this feature yet. I'm not sure it is the right way to do it, or if it is actually needed. The more I look at it the more I would recommend you to go with a pecl package, get feedbacks from the actual users (framework&co) and come back once you have reached more maturity with both the design and the implementation of this feature. Don't be afraid to miss 5.4 either, next one comes next year :) Cheers, > Hello, > > Voting is now open for the weak references RFC. > > The RFC and patch can be found here: > https://wiki.php.net/rfc/weakreferences > > You can vote here: > https://wiki.php.net/rfc/weakreferences/vote > > I don't seem to be able to vote myself and I'm not sure if that's an > error or not. > > Regards, > > Hannes Landeholm > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54283 — Etienne Kneuss — 2011-08-01T21:00:19+00:00 URL: https://externals.io/message/54277#54283 · In reply to: #54281 Hello, > hi, > > You have to start a new thread to begin a vote, see the voting RFC. So > everyone will see it. > > However, I feel like it is premature to vote on that one. For one, I'm > not convinced by this feature yet. I'm not sure it is the right way to > do it, or if it is actually needed. The more I look at it the more I > would recommend you to go with a pecl package, get feedbacks from the > actual users (framework&co) and come back once you have reached more > maturity with both the design and the implementation of this feature. I'll make a PECL ext based on this patch. That should make this RFC/vote moot. Best, > > Don't be afraid to miss 5.4 either, next one comes next year :) > > Cheers, > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #54284 — Hannes Landeholm — 2011-08-01T22:30:12+00:00 URL: https://externals.io/message/54277#54284 · In reply to: #54281 > However, I feel like it is premature to vote on that one. For one, I'm > not convinced by this feature yet. I'm not sure it is the right way to > do it, or if it is actually needed. Using weak references is the only way to design non caching references and the only way to correctly implement the observer pattern without leaking memory as outlined in the RFC. I need this feature and 12 others also do who voted on bug #52318. For everyone that votes on a ticket there's probably a hundred others who also needed it but didn't find the ticket, didn't bother creating an account or didn't bother voting. When it's hard to contribute people won't bother. I'm trying to speak for the users that have too little time to argue in mailing lists or write RFC's or learn C or jump trough endless hoops in a process designed so that the core development team can ignore the community more democratically. The users that just suck it up and design their applications or frameworks poorly instead because they don't have time. I can also tell some of my own experience as an additional use case. Since this feature did not exist I was forced to implement caching referencing in my framework which resulted in huge memory problems during certain object intensive procedures. An application I developed for a customer crashed when it bumped into 330 MB of memory. I had to resort to unsetting stuff manually - basically making hacks which did memory management - which is not something you're suppose to be required to do in a memory managed language like PHP. I anticipated this problem when designing my framework but could not do anything about it since PHP did not provide me with the necessary tools to actually solve it. As Ethan Nicolas puts it in the last sentence of this paragraph: ""This might look okay on the surface, but the strong reference to widget will almost certainly cause problems. We have to know (with 100% certainty) when a particular Widget's serial number is no longer needed, so we can remove its entry from the map. Otherwise we're going to have a memory leak (if we don't remove Widgets when we should) or we're going to inexplicably find ourselves missing serial numbers (if we remove Widgets that we're still using). If these problems sound familiar, they should: they are exactly the problems that users of non-garbage-collected languages face when trying to manage memory, and we're not supposed to have to worry about this in a more civilized language like Java."" Just as "classes is not needed when you have arrays with functions in them", is week references is not needed "when you can implement ugly memory management unset hacks". A language should provide the tools a programmer need to design their applications well. Currently I am unable to design my applications well because PHP does not support designing my ID-to-object-referencing-component well because PHP does not support weak references. Tell me how I should design an application so that you can get an "already initialized object" for a certain ID while enabling the GC to collect it without using weak referencing. Then I'll be convinced that the feature "is not needed". > The more I look at it the more I > would recommend you to go with a pecl package, get feedbacks from the > actual users (framework&co) and come back once you have reached more > maturity with both the design and the implementation of this feature. I'm not sure how to respond to that. "The more I look at it" does not parse as an actual argument of anything in my head. Be more specific. I strongly disagree that Weak References should be buried in a PECL extension. I speak for a lot of PHP developers when I say that I don't want to have anything to do with PECL. I'm a programmer - I don't want to spend valuable time compiling and configuring anything. Compiling is a nightmare for most PHP developers - especially on Windows. A developer is a user - if it's not simple to develop he will move to other frameworks or languages. PECL is great for experimental, complex stuff like APC or very specific types of integration and purposes. Not specific language features - they should be implemented in the language. Nobody likes writing platform-dependent code. Also I'm not sure what you expect when you say that it "reached more maturity". To what end? A feature doesn't really get much more well defined and simple than this. It's like the whole "it's a single class with two functions" and "it's implemented as a fundamental component in other major OO languages" counts for nothing. Like all other languages perhaps accidentally implemented it without actually needing it and now we need to discuss the feature again endlessly and "gather community feedback" for years even though all the research has already been done. It will be simple to extend the class with additional methods if other use cases should emerge. > Don't be afraid to miss 5.4 either, next one comes next year :) I've been a PHP fan for years and endured the patchy OO implementation and the limitations that has come with the language for the simplicity. Unfortunately I don't have time to wait for years even if many of you guys do. If I did I wouldn't have bothered writing the RFC or writing in this mailing list. You guys should look into this new rapid release cycle thing. It's the next iteration of software development. ~Hannes > hi, > > You have to start a new thread to begin a vote, see the voting RFC. So > everyone will see it. > > However, I feel like it is premature to vote on that one. For one, I'm > not convinced by this feature yet. I'm not sure it is the right way to > do it, or if it is actually needed. The more I look at it the more I > would recommend you to go with a pecl package, get feedbacks from the > actual users (framework&co) and come back once you have reached more > maturity with both the design and the implementation of this feature. > > Don't be afraid to miss 5.4 either, next one comes next year :) > > Cheers, > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54286 — Adam Harvey — 2011-08-02T05:11:41+00:00 URL: https://externals.io/message/54277#54286 · In reply to: #54280 > aharvey: I'm surprised you voted no since you seemed content with the > answers you got earlier. Do you have some special objection in mind? Sorry, I meant to send an e-mail last night explaining the -1 and completely forgot before I went to bed. I guess it may be moot now, but for the record... I've no issue with the answer that you gave to my earlier question, but I agree with Stas (and apparently Etienne): I'm not really convinced this needs to be in mainline at the moment. I don't doubt that weak references have the potential to be useful, but given this can be implemented in PECL, I'd rather revisit this once there's more data on how useful this is this the community as a whole — it's not something I've personally ever needed in PHP or even really heard anyone ask for, outside of the feature request linked in the RFC (which is about 115th on the overall list of feature requests sorted by vote, although I don't think the voting system is remotely representative anyway). If the implementation works out well there, there's no reason we can't revisit the bundling decision for 5.5 next year, but it's a lot easier to get something in than remove something later. There are a number of packages that have been promoted after getting use in PECL (json, zip and PDO spring to mind immediately), so it's a well-worn path. Adam --- ## #54290 — Lester Caine — 2011-08-02T15:16:25+00:00 URL: https://externals.io/message/54277#54290 · In reply to: #54284 Hannes Landeholm wrote: > I've been a PHP fan for years and endured the patchy OO implementation > and the limitations that has come with the language for the > simplicity. Unfortunately I don't have time to wait for years even if > many of you guys do. If I did I wouldn't have bothered writing the RFC > or writing in this mailing list. You guys should look into this new > rapid release cycle thing. It's the next iteration of software > development. The fast development root does seem to have been a little screwed up recently, but if there is nothing in an extension that requires direct access to the core and that extension CAN simply be enabled as required, then pecl is the way to go? We do need the pecl area to be properly included in the build process with windows builds being created just as they used to be, but the process is working fine for APC and perhaps the plan should be to moving some more extensions that are being worked on between PHP releases into the pecl process? It used to be that many of the extensions I used were managed in pecl ... and I'd be quite happy if they moved back there. There is nothing stopping 'Weak References' being added by those who want them ... but I can't see the point myself when running scripts live. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54294 — Hannes Landeholm — 2011-08-02T18:06:23+00:00 URL: https://externals.io/message/54277#54294 · In reply to: #54290 I've talked to Etienne and he still believes we should vote on this so the vote is still up. He just replied to quickly. If the vote fails the patch can still be implemented in a PECL extension. There's no point canceling the vote or the RFC - it's still valid and ongoing, and there is still time for discussion. The problem is that PECL is not an option for all users. If you're using shared hosting and otherwise don't have control over what extensions is loaded or not then essentially you'll be unable to use a framework that takes advantage of weak references. That's the reality of many freelancing developers and small-scale sites out there. It's especially problematic for framework designers that builds ORM-layers - they can't tell their users "oh btw you need to install this non standard PECL extension for it to work". Or rather, you can but then the user will be angry. I don't think "because they can" is a good argument for why features should generally be outsourced as PECL extensions. Complex, experimental stuff that solves specific integration or performance problems is great for PECL. But generic object orientation design fundamentals should be implemented in the core since people rather have their framework leak a bit more memory (and risk running out of it in edge cases) or design their application more clumsy than depend on a non-standard PECL extension. It's about allowing people to do elegant design. A good developer would choose compatibility over elegant design any day - so if the language wants people to do design great applications the language needs to provide those tools natively. I realize I need to provide some kind of realistic scenario for you to understand so let's put ourselves in the shoes of Joe Codeguy - he's currently designing the an application that will edit inventory details at a small company with 10 employees. It is hosted at a shared hosting provider since they are running a tight budget. They can't afford their own servers or an IT guy. The employers regularly login to the application and updates the inventory. Joe Codeguy has designed the application so that there are one Product class that is loaded from the database where each "products" table row corresponds to a product. Certain function in the application runs a MySQL procedure that updates a certain complex selection of products in the products database rendering the currently loaded products in memory obsolete since they might have been updated. After this procedure runs all Product class objects in memory will need to be reloaded. Joe Codeguy fixes this by implementing the observer pattern (PEAR Event_Dispatcher) so that whenever a Product is loaded or created it registers itself on a global event called "EVENT_PRODUCT_RELOAD". He then proceeds to trigger the event whenever the complex MySQL procedure updates the database table. Everything seems to be working fine so he deploys the application. One days later the customer complains that a certain critical operation no longer works. Joe then find a subroutine while debugging that loops trough a quite large selection of thousands of products one by one and makes some complicated calculations. During this loop the application faces a out of memory condition. Joe thinks this is strange because it only operates on one product at a time. He then realizes that the observer registration prevents the products from being garbage collected properly since they are strongly referenced by Event_Dispatcher. Thankfully PHP implements weak references so he can correct Event_Dispatcher to use weak referencing instead. However it's outsourced into a PECL extension and since Joe cannot install extensions into the production server he is forced to use unset hacks in the faulty loops to correct the issue. Joe deploys the application again and can only hope that this was the only loop that triggered the memory problem and that the application doesn't crash anywhere else when the products table grows larger. Also even if an application doesn't run out of memory there might be a serious performance impact from the memory leaked by objects that can't be collected properly. If an application peaks at 15 MB instead of 25 MB, the server can run 40% more child threads in parallel. Regards, ~Hannes > > The fast development root does seem to have been a little screwed up > recently, but if there is nothing in an extension that requires direct > access to the core and that extension CAN simply be enabled as required, > then pecl is the way to go? We do need the pecl area to be properly included > in the build process with windows builds being created just as they used to > be, but the process is working fine for APC and perhaps the plan should be > to moving some more extensions that are being worked on between PHP releases > into the pecl process? It used to be that many of the extensions I used were > managed in pecl ... and I'd be quite happy if they moved back there. There > is nothing stopping 'Weak References' being added by those who want them ... > but I can't see the point myself when running scripts live. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=**contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/**index.php  I've talked to Etienne and he still believes we should vote on this so the > vote is still up. He just replied to quickly. If the vote fails the patch > can still be implemented in a PECL extension. There's no point canceling the > vote or the RFC - it's still valid and ongoing, and there is still time for > discussion. > > .. snip ... I think at this point everyone is well aware that you would like this feature implemented. I would like to make a couple points here, first I is that PECL is not a place for a extension to rot, that statement makes absolutely no sense to me. PDO I recall years ago getting from PECL, Http a extension I often use, was recently on this list if I recall to be moved into the core. I'm sure there are plenty of people on this list that were part of extension's PECL -> CORE lifecycles that could add several more examples to the list. I believe PECL Would be a great place for something like this that was is entirely understood or has overwhelming support in my opinion. I am really not sure how comfortable I am with a feature as new as this being in the PHP on my servers. Some form of incubation, testing and use feedback only makes sense to me. Second I would like to talk a little bit about weak references for those who are not familiar with them or have thus far only read your very strong pro-opinion. I would like to make it very clear with the simple fact that weak references are not required, ever by any language. They are a convenience, not a solution to a unsolvable problem. I believe that if anything weak references encourage laziness in design, it causes the referential integrity that I am accustomed to is broken, and can often lead to more code and checks then it relieves. It is very easy to run into unexpected bugs and in a language like PHP, where you don't get a NPE when you try to access a `NULL` method of a non object, you get a fatal error, this doesn't seem very appealing to me. Only under very specific cases of caching patterns as you have previously mentioned is such a pattern even recognized to -have a place for use that isn't just plain wrong- -not a requirement- by me. In PHP, I believe a web or cli app that uses enough resources to bomb memory limits on a server, needs to be re-factored. I have definitely written multi-process PHP daemons that go to disk or over the network for taxing operations that need cached and had very little trouble with rudimentary memory management patterns, so from my perspective I can't really see why given the toolset PHP provides that this is such a problem. This is just my opinion, I don't have a strong opposition to this feature, anything "new" to PHP I usually get excited about, I simply wanted to give a few counter arguments as the fact that this feature is being presented as a dire and long over due missing feature to the language is a bit dramatic. Not saying its useless and doesn't belong in PHP or I would never want it to exists, I just would hate to see something rushed through that didn't get a bit of testing and typical QA from a language that affects millions of people. -Chris --- ## #54299 — Frank M. Kromann — 2011-08-02T23:59:34+00:00 URL: https://externals.io/message/54277#54299 · In reply to: #54294 Adding a new feature to the latest version of PHP will not make it available to users of shared hosting. Many of these are running on older versions and it takes time for them to get updated to the latest. - Frank > I've talked to Etienne and he still believes we should vote on this so the > vote is still up. He just replied to quickly. If the vote fails the patch > can still be implemented in a PECL extension. There's no point canceling the > vote or the RFC - it's still valid and ongoing, and there is still time for > discussion. > > The problem is that PECL is not an option for all users. If you're using > shared hosting and otherwise don't have control over what extensions is > loaded or not then essentially you'll be unable to use a framework that > takes advantage of weak references. That's the reality of many freelancing > developers and small-scale sites out there. It's especially problematic for > framework designers that builds ORM-layers - they can't tell their users "oh > btw you need to install this non standard PECL extension for it to work". Or > rather, you can but then the user will be angry. > > I don't think "because they can" is a good argument for why features should > generally be outsourced as PECL extensions. Complex, experimental stuff that > solves specific integration or performance problems is great for PECL. But > generic object orientation design fundamentals should be implemented in the > core since people rather have their framework leak a bit more memory (and > risk running out of it in edge cases) or design their application more > clumsy than depend on a non-standard PECL extension. It's about allowing > people to do elegant design. A good developer would choose compatibility > over elegant design any day - so if the language wants people to do design > great applications the language needs to provide those tools natively. > > I realize I need to provide some kind of realistic scenario for you to > understand so let's put ourselves in the shoes of Joe Codeguy - he's > currently designing the an application that will edit inventory details at a > small company with 10 employees. It is hosted at a shared hosting provider > since they are running a tight budget. They can't afford their own servers > or an IT guy. The employers regularly login to the application and updates > the inventory. Joe Codeguy has designed the application so that there are > one Product class that is loaded from the database where each "products" > table row corresponds to a product. Certain function in the application runs > a MySQL procedure that updates a certain complex selection of products in > the products database rendering the currently loaded products in memory > obsolete since they might have been updated. After this procedure runs all > Product class objects in memory will need to be reloaded. Joe Codeguy fixes > this by implementing the observer pattern (PEAR Event_Dispatcher) so that > whenever a Product is loaded or created it registers itself on a global > event called "EVENT_PRODUCT_RELOAD". He then proceeds to trigger the event > whenever the complex MySQL procedure updates the database table. Everything > seems to be working fine so he deploys the application. One days later the > customer complains that a certain critical operation no longer works. Joe > then find a subroutine while debugging that loops trough a quite large > selection of thousands of products one by one and makes some complicated > calculations. During this loop the application faces a out of memory > condition. Joe thinks this is strange because it only operates on one > product at a time. He then realizes that the observer registration prevents > the products from being garbage collected properly since they are strongly > referenced by Event_Dispatcher. Thankfully PHP implements weak references so > he can correct Event_Dispatcher to use weak referencing instead. However > it's outsourced into a PECL extension and since Joe cannot install > extensions into the production server he is forced to use unset hacks in the > faulty loops to correct the issue. Joe deploys the application again and can > only hope that this was the only loop that triggered the memory problem and > that the application doesn't crash anywhere else when the products table > grows larger. > > Also even if an application doesn't run out of memory there might be a > serious performance impact from the memory leaked by objects that can't be > collected properly. If an application peaks at 15 MB instead of 25 MB, the > server can run 40% more child threads in parallel. > > Regards, > > ~Hannes > > > > > […] --- ## #54300 — Lester Caine — 2011-08-03T00:26:12+00:00 URL: https://externals.io/message/54277#54300 · In reply to: #54294 Hannes Landeholm wrote: > Certain function in the application runs a MySQL procedure that updates a > certain complex selection of products in the products database rendering the > currently loaded products in memory obsolete since they might have been > updated. Then you are caching the wrong data in memory? Following an update like that one would either have to commit the changes or rollback. So the data has to be reloaded from the server anyway. You can't rely on any of the data already loaded. > Joe deploys the application again and can only hope that this was the > only loop that triggered the memory problem and that the application > doesn't crash anywhere else when the products table grows larger. So you are trying to load lots of unnecessary data from the database through poor design. Redesign the data so it works properly ... or switch to a database that handles business logic via triggers properly ;) You should only be downloading the data you need to look at, leave the volume data on the server. The majority of my business logic is done in the database (Firebird) and I simply can't see how I would ever fall into the trap you seem to be creating? Perhaps I am doing something wrong, but my systems all run multiuser real time and handle large numbers of records without these sorts of problem. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54301 — Stas Malyshev — 2011-08-03T00:39:12+00:00 URL: https://externals.io/message/54277#54301 · In reply to: #54284 Hi! > lists or write RFC's or learn C or jump trough endless hoops in a > process designed so that the core development team can ignore the > community more democratically. The users that just suck it up and > design their applications or frameworks poorly instead because they > don't have time. I notice some tone of hostility here. Please understand that while your problem seems to you the most important thing missing in the language, and maybe for you it is, PHP has millions of users, which need stable and predictable environment. Which means relying on your or my personal opinion about some matter is a dangerous thing as it can influence how millions of people work. This is why we tend to be careful with adding stuff to the language, especially stuff that has potential long-term consequences, most of which we don't even know about until this thing has been tried in the field. Also, it is very hard to substantially change stuff in the core once it's there as we have to preserve BC. This is why we tend to recommend to try the code outside the core if possible before taking it in. > I'm not sure how to respond to that. "The more I look at it" does not > parse as an actual argument of anything in my head. Be more specific. > > I strongly disagree that Weak References should be buried in a PECL You seem to regard PECL as some kind of place where code goes to die. This is not so. Of course, some PECL extensions do wither and die of neglect, but others work just fine and have large user base - such as memcache support, apc, etc. Recommendation of PECL is not a punishment or disregard for your ideas or code - it is a recognition of the fact that not every new idea should immediately be implemented in the core. > Also I'm not sure what you expect when you say that it "reached more > maturity". To what end? A feature doesn't really get much more well > defined and simple than this. It's like the whole "it's a single class If you think all proposals are more complex than this, you are obviously wrong. Most of recently added things into 5.4 in fact are conceptually simpler. > simplicity. Unfortunately I don't have time to wait for years even if > many of you guys do. If I did I wouldn't have bothered writing the RFC > or writing in this mailing list. You guys should look into this new > rapid release cycle thing. It's the next iteration of software > development. Rapid release cycle doesn't mean that we immediately put into the release everything that was proposed up to the last second when it's supposed to be released. If you need a solution for your use cases, I don't see how PECL extension wouldn't be fine. If you're looking for something which would run on shared hosting, many shared hosts wouldn't support 5.4 for a long time even after it's released. Also, I am sure there are ways to implement the same ideas without this specific class (indirection can be one idea that may work - it's in fact what PHP does internally with objects). It may not be the best way, but I think it's doable. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54302 — Hannes Landeholm — 2011-08-03T00:44:33+00:00 URL: https://externals.io/message/54277#54302 · In reply to: #54297 > I would like to make a couple points here, first I is that PECL is not > a place for a extension to rot, that statement makes absolutely no > sense to me. PDO I recall years ago getting from PECL, Http a > extension I often use, was recently on this list if I recall to be > moved into the core. I'm sure there are plenty of people on this list > that were part of extension's PECL -> CORE lifecycles that could add > several more examples to the list. I believe PECL Would be a great > place for something like this that was is entirely understood or has > overwhelming support in my opinion. I don't agree with the concept of putting new feature in PECL itself. I would happily agree with putting it there if actually believed that it was there it belonged. Theoretically speaking weak references _is_ a core feature since it touches on garbage collection. If you followed the discussion the last weeks you'll see that the patch was intentionally weakened in functionality so no changes would have to be made to the GC (The "catch collection event" feature was removed/not implemented.). The reason behind this was so that it would not require much testing and have a larger chance of being merged into 5.4. This had the side effect of making it technically implementable as a PECL extension which was never intended. Rather I feel like this is instead used as an opportunity to delay it because it is difficult to put yourself in the situation of the marginal number of PHP developers that needs it. Yes, I admit that the number of people that care about the feature and knows what weak references are can be described as "marginal" but I also believe all frustrations are worth taking a shot at - especially the frustrations of the more advanced developer segment of the community. If they are not given the tools they need to implement the great design they envision they will look for other tools=languages instead and move on. The more great programmers that wants to use PHP the better position PHP has as a language and community. Also I think WR will have a huge impact when frameworks, event handlers, observer abstractions etc implements weak references and reduces the memory usage on a lot of applications out there. >I am really not sure how > comfortable I am with a feature as new as this being in the PHP on my > servers. Some form of incubation, testing and use feedback only makes > sense to me. If you don't use weak references there's no risk that anything breaks. The alpha and RC stage is exactly what incubation, testing and feedback is for. > Second I would like to talk a little bit about weak references for > those who are not familiar with them or have thus far only read your > very strong pro-opinion. I would like to make it very clear with the > simple fact that weak references are not required, ever by any > language. They are a convenience, not a solution to a unsolvable > problem. I believe that if anything weak references encourage laziness > in design, it causes the referential integrity that I am accustomed to > is broken, and can often lead to more code and checks then it > relieves. No. Weak References _is_ a solution to an unsolvable problem. The problem is a subset of "decoupling" or "separation of concerns" theory in OOP. An example of the problem can be stated like this: - You need to design a framework in PHP. The framework should be decoupled from the application that uses it. This means that the data the application requests is undefined from the frameworks perspective. It should contain an ORM layer that maps exactly one object instance to a certain table row. If the frameworks fails to do this the application will have parallel instances of the same object row which is a corrupt data state. The application requests object instances by ID selection. The application may request a large number of object instances but never references more than what can be kept in memory at the same time. Design the ORM layer so that the application never faces an OOM condition. You may have the opinion that object oriented design problems aren't "real problems". Fundamentally, design patterns does not solve any pure mathematical problems. Design patterns does not allow you to sort faster than O(n log n). Rather they solve an economical problem. By giving programmers the tools they need to write elegant code, the code becomes easier to understand, test and maintain. It saves the developer's time and the company's money. And most importantly, it makes programming fun. ;) >It is very easy to run into unexpected bugs and in a > language like PHP, where you don't get a NPE when you try to access a > `NULL` method of a non object, you get a fatal error, this doesn't seem > very appealing to me. Only under very specific cases of caching > patterns as you have previously mentioned is such a pattern even > recognized to -have a place for use that isn't just plain wrong- -not > a requirement- by me. So if a language feature allows a programmer to write more messier code the language should not provide those features? I disagree with that. > In PHP, I believe a web or cli app that uses enough resources to bomb > memory limits on a server, needs to be re-factored. I have definitely > written multi-process PHP daemons that go to disk or over the network > for taxing operations that need cached and had very little trouble > with rudimentary memory management patterns, so from my perspective I > can't really see why given the toolset PHP provides that this is such > a problem. It's not a mathematical problem. Yes you can still design your code so that it breaks responsibilities and decoupling. You can write special unset functions and document that they need to be called whenever objects are "not used anymore". If you're mainly a C programmer I also understand your indifference to having the userland developer worry about memory management. However, I think PHP should be a civilized language that takes care of stuff like that. > This is just my opinion, I don't have a strong opposition to this > feature, anything "new" to PHP I usually get excited about, I simply > wanted to give a few counter arguments as the fact that this feature > is being presented as a dire and long over due missing feature to the > language is a bit dramatic. Not saying its useless and doesn't belong > in PHP or I would never want it to exists, I just would hate to see > something rushed through that didn't get a bit of testing and typical > QA from a language that affects millions of people. I had a two week discussion period that was mostly silent and I felt the consensus was generally in favor of the feature which is why I started the vote. It's a single class with two functions. It implements a widely researched and adopted design pattern. It's not a new or experimental concept. It will get "a bit of testing" and it has been given opportunity of "typical QA" like other features voted for an accepted into 5.4. ~Hannes --- ## #54303 — Christopher Jones — 2011-08-03T01:24:24+00:00 URL: https://externals.io/message/54277#54303 · In reply to: #54302 > I had a two week discussion period that was mostly silent and I felt > the consensus was generally in favor of the feature which is why I > started the vote. @internals silence on new features can be interpreted both ways. Looking at the general feeling now I think it is time to accept the feature will be in PECL. Later you can come back and renew discussion about core inclusion. To push the topic too far right now will only antagonize folk. The best path forward is to make sure the extension has good code coverage, works in all possible PHP branches, is kept up to date, and is picked up by some good PHP projects. I know everyone here appreciates the time and constructive arguments you have put into this and would like to make sure you keep contributing to PHP. You've got a lot further than some feature proposers have in the past so take some credit for your efforts. Chris -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #54304 — Hannes Landeholm — 2011-08-03T01:25:07+00:00 URL: https://externals.io/message/54277#54304 · In reply to: #54301 Hello Stas, On 3 August 2011 02:39, Stas Malyshev wrote:> > I notice some tone of hostility here. I'm not hostile. Perhaps a bit disappointed that the PECL objection wasn't brought up earlier in the discussion period so It could have been toughly discussed. > /* snip */ > This is why we tend to recommend to try the code outside the core if > possible before taking it in. Yes, this is self evident. > You seem to regard PECL as some kind of place where code goes to die. This > is not so. Of course, some PECL extensions do wither and die of neglect, but > others work just fine and have large user base - such as memcache support, > apc, etc. Recommendation of PECL is not a punishment or disregard for your > ideas or code - it is a recognition of the fact that not every new idea > should immediately be implemented in the core. See the first paragraph in my previous post. > If you think all proposals are more complex than this, you are obviously > wrong. Most of recently added things into 5.4 in fact are conceptually > simpler. Weak Reference: An object reference that does not prevent GC. I can't imagine something more conceptually simple although the use cases are not very simple. I don't think it's obvious why I am "obviously wrong". > Rapid release cycle doesn't mean that we immediately put into the release > everything that was proposed up to the last second when it's supposed to be > released. I'm referring to the fact that PHP has a major update once a year. Looking at it from an agile perspective this is insanely slow. I think you should use smaller iterations and release faster. The new Mozilla release schedule is a good example. > If you need a solution for your use cases, I don't see how PECL extension wouldn't be fine. I have no problem compiling extensions and I also don't have any customers on share hosting. Although it wastes a bit more of my time I'm personally fine with PECL. I'm contributing to open source though so I'm concerned with the users that won't be able to run my code because they can't install PECL extensions. I'm also worried that it will takes years for WR to be moved to the core and that nobody will notice or use it. PHP deserves weak references. Not in a year but today. ~Hannes --- ## #54305 — Hannes Landeholm — 2011-08-03T01:31:47+00:00 URL: https://externals.io/message/54277#54305 · In reply to: #54302 Tired... > I don't agree with the concept of putting new feature in PECL itself... should of course be: >I don't disagree with the concept of putting new feature in PECL itself... ~Hannes --- ## #54306 — Stas Malyshev — 2011-08-03T01:39:29+00:00 URL: https://externals.io/message/54277#54306 · In reply to: #54304 Hi! > I'm referring to the fact that PHP has a major update once a year. > Looking at it from an agile perspective this is insanely slow. I think > you should use smaller iterations and release faster. The new Mozilla > release schedule is a good example. Having major changes more frequent would mean people that use PHP would be forced to constantly update their systems to keep up - or would not use most of the new features. It would also mean most of new releases will be unstable for most of their lifecycle - as once they'd stabilize we'd have new version on the way. And we'd need massive quantity of resources to test and fix those. Just for perspective - we have a lot of PHP 4 code still out there and many still run 5.1. Most projects still can't afford not to have 5.2 support - even though this version is officially dead. Now let's suppose we are "agile" and have 3 versions in a year. That means developers would have to test on 6 or 9 versions of PHP instead of 2 or 3 now. Or people would just ignore all new stuff - and what's the point then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54307 — Rasmus Lerdorf — 2011-08-03T06:34:52+00:00 URL: https://externals.io/message/54277#54307 · In reply to: #54304 > I have no problem compiling extensions and I also don't have any > customers on share hosting. Although it wastes a bit more of my time > I'm personally fine with PECL. I'm contributing to open source though > so I'm concerned with the users that won't be able to run my code > because they can't install PECL extensions. I'm also worried that it > will takes years for WR to be moved to the core and that nobody will > notice or use it. PHP deserves weak references. Not in a year but > today. Honestly, pecl is kind of self-selecting. APC is installed on millions of servers and it lives in pecl. It is installed everywhere because it is an extremely useful extension and distros tend to package it up promptly for that reason as well. If weak references is a highly desirable feature that will make every complex framework use less memory, then I don't see why it wouldn't follow APC's path and end up on millions of servers. Note also that there are distros that unbundle core extensions and move them into separate packages which makes them indistinguishable from pecl extensions as far as the user is concerned. Realistically, very few end users are installing from the php.net sources. Just about everyone installs their distro's version of PHP with whatever extensions the distro maintainer has decided to include by default. The major frameworks/CMS systems are also packaged up and carry along dependencies which sometimes includes extension packages. So again, the line between core and pecl is very fuzzy here since you could easily have your framework have a dependency on a pecl extension. And the final point is that large shared hosting farms is kind of old fashioned these days. Modern hosting is done with dedicated machine slices, but there are of course a lot of these legacy shared hosting farms around. But, given these are legacy systems they are not likely to rush to upgrade to 5.4 and by the time 5.4 becomes prevalent how many users are really still going to be on a shared web server config? I think the only valid point for putting this in core is that it does feel more like a core feature than a pecl add-on. However, a number of us are uncomfortable with the impact of it and would like to understand better how people other than yourself would use it, or more likely, mis-use it. -Rasmus --- ## #54308 — Lester Caine — 2011-08-03T07:35:10+00:00 URL: https://externals.io/message/54277#54308 · In reply to: #54307 Rasmus Lerdorf wrote: > I think the only valid point for putting this in core is that it does > feel more like a core feature than a pecl add-on. However, a number of > us are uncomfortable with the impact of it and would like to understand > better how people other than yourself would use it, or more likely, > mis-use it. I think this is were I am sitting at the moment ... If a script needs to tidy up memory because something has gone wrong, then in my book the script is faulty? The example of why it is needed does not make sense to me, probably because I don't understand it, firing an action on the database end and trying to then simply tidy up the the php end cache without a clean reload just seems wrong? How do you know what the stored procedure/trigger/business logic has done to the underlying data? But I've never used MySQL :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #54309 — Lars Schultz — 2011-08-03T07:44:39+00:00 URL: https://externals.io/message/54277#54309 · In reply to: #54308 Am 03.08.2011 09:35, schrieb Lester Caine: > I think this is were I am sitting at the moment ... If a script needs to > tidy up memory because something has gone wrong, then in my book the > script is faulty? The example of why it is needed does not make sense to > me, probably because I don't understand it, firing an action on the > database end and trying to then simply tidy up the the php end cache > without a clean reload just seems wrong? How do you know what the stored > procedure/trigger/business logic has done to the underlying data? But > I've never used MySQL :) > I think you might have misunderstood the use case Hannes mentioned. It is a valid problem and weak references are a neat and indeed the only clean solution (so far) to it. I ran into similar Problems and it costs a lot of code and bugfixing to work around the problem, both with the observer-pattern and object-mapper-cache. Do not ridicule his strategy just because you've never run into the problem. --- ## #54310 — Hannes Landeholm — 2011-08-03T10:25:59+00:00 URL: https://externals.io/message/54277#54310 · In reply to: #54309 Hello, We had a healthy discussion around WR and I have been able to express my concerns. The consensus is clearly to put it in a PECL extension so I think this discussion should move on to the practical matters of doing this. I suggest aborting the vote and changing the RFC state to something like "Transfered to PECL". ~Hannes --- ## #54311 — Pierre Joye — 2011-08-03T10:32:47+00:00 URL: https://externals.io/message/54277#54311 · In reply to: #54310 hi Hannes, I would suggest to still update the RFC with the various very instructive comments and example use cases you use in this thread. Doing the same in the long run should help as well to understand the goals, implementations, etc., for the pecl users or for the 2nd attempt to get it in the core, if still desired. Cheers, > Hello, > > We had a healthy discussion around WR and I have been able to express > my concerns. The consensus is clearly to put it in a PECL extension so > I think this discussion should move on to the practical matters of > doing this. I suggest aborting the vote and changing the RFC state to > something like "Transfered to PECL". > > ~Hannes > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54313 — Hannes Landeholm — 2011-08-03T12:49:10+00:00 URL: https://externals.io/message/54277#54313 · In reply to: #54311 Good idea. I will see what I can do when I get time. ~Hannes > hi Hannes, > > I would suggest to still update the RFC with the various very > instructive comments and example use cases you use in this thread. > Doing the same in the long run should help as well to understand the > goals, implementations, etc., for the pecl users or for the 2nd > attempt to get it in the core, if still desired. > > Cheers, > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/54277.md?page=2