Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

Sam Barrow wrote: > I agree with this 100%, is this something that could be changed? I don't > see a reason behind it. > > On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote: > >> internal class/function with the same name. >> >> Dmitry, what's the reason this lookup logic wasn't used in your patch? Hi, Actually, there several good reasons. For one, every single unknown class declaration inside a namespace would require a double check of class existence, hitting performance. Here's another example showing the "gotcha" that is inherent: file1.php: <?php namespace Foo; class IwantThis {} ?> file2.php: <?php class IwantThis {} ?> file3.php: <?php namespace Foo; include 'file2.php'; function __autoload($class) { include 'file1.php'; // stupid but illustrates the point } $a = new IwantThis; ?> Currently, executing file3.php would result in this logic chain: 1) does Foo::IwantThis exist? no => step 2 2) does internal class IwantThis exist? no => step 3 3) try autoloading Foo::IwantThis, loads file1.php, now Foo::IwantThis exists If this logic chain were changed to instead check for any globally defined class of that name, the logic chain would be: 1) does Foo::IwantThis exist? no => step 2 2) does ::IwantThis class exist? yes => use ::IwantThis In other words, it would completely break autoloading for namespaced classes. Of course, this is the same problem as conflicting with internal classnames, but the scope of the problem is far larger because there are so few classes internal to PHP, and even fewer that are likely to conflict with unqualified names. So, it could be changed (patch attached for 5.3 to prove the concept, it's not the best way to do this but shows the way it could be done), but the price would be an absolute requirement that all classes be explicitly "use"d in some manner inside a namespace. Greg