Re: Namespaces in PHP 6 - ++$take

From: Date: Fri, 10 Nov 2006 18:05:41 +0000
Subject: Re: Namespaces in PHP 6 - ++$take
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-26477@lists.php.net to get a copy of this message
On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
I don't think namespaces are a magic bullet. As it stands, it's impossible to use namespaces without a third party patch that may or may not work. I strongly believe that if namespaces are implemented in PHP 6, most of our prefixing/symbol collisions will go away as people migrate. It's much easier to track down a failed import than to comment out a function declaration in the PHP source.
PHP 6 is not yet out and probably won't be production quality for quite some time. Which means that migration to it en mass is probably not going to happen this decade :-). If we take 5.x adoption as a benchmark it took it over 2 years to even reach the 10% mark and big PHP apps still (with good reason) focus on the much larger PHP 4 market. Namespacing core classes/function would be a supremely bad idea as it could quite literally break every single application. You also need to consider that until PHP X attains at least 50% or more market penetration few people would be willing to write applications that require this version of PHP to work. This is why many of the projects and companies I am familiar still write new code in PHP 4 rather then in PHP 5, despite that version having numerous perceived advantages.
I also don't deny that there will be a minor performance hit. There are a ton of other things in PHP that reduce performance.. the idea is to find a balance of which ones are worth it (as we did with OOP and Unicode), and I believe that namespaces are worth it. I also know that I'm not alone in this.
I think adoption rates speak for themselves, I think there is far more demand for a fast & stable PHP then for syntatic sugar features which seem extremely useful, but in the end prove to carry too much baggage. Ilia Alshanetsky

« previous php.internals (#26477) next »