> That's a bit of a circular logic no? There are indeed technical > challenges to implementing namespaces, these reasons have been covered > in previous discussions many times, since no adequate solution was > devised they were never implemented. Once those issues are resolved or > at the very least solutions are known, we can consider whether or not > this is something that's truly needed.
I think we got hung up on political issues. The last discussion was not technical (other than "no, you can't use ! -- it's already an operator). I'd love to move onto discussing the technical hurdles, but I don't think we came to a political conclusion, yet. > I think this is a bogus argument. In order to benefit from namespaces > you need to use them, just like to benefit from containment through > prefixing you need to prefix functions/classes/etc... Namespaces are not > a magic bullet that will instantly make your problems go away and make > your code better. If anything it'll make code complex and intertwined, > introduce serious scope issue most people have not had to consider up > until now and so on. It will without a doubt increase language > complexity as well, which generally translates to a loss in performance. 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. 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. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
