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
