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 On 2 August 2011 17:16, Lester Caine <les...@lsces.co.uk> wrote: > > 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<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<http://www.firebirdsql.org/index.php> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
