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
On 8/2/11 11:06 AM, Hannes Landeholm wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
