Re: Namespaces and __autoload()

Dmitry Stogov wrote:

This is an implementation of Stas idea. 1) Look for existent class in current namespace 2) Look for existent internal class 3) Try to autoload class from current namespace

both ways have a wtf factor in that class with names matching 'internal' class names behave differently. afaict you would not be able to autoload class Exception from within namespace Foo in the example below. currently one cannot create classes named the same as 'internal' classes ... obviously. I would consider making internal class names illegal in namespaces. this would be consistent simple and clear. also I don't see what would be gained from being allowed to do: <?php namespace Foo; class Exception extends Exception {}; I assume all the SPL stuff wont be moved into into own namespace straight away with regard to BC, would that be correct? rgds, Jochem

Thanks. Dmitry.

-----Original Message----- From: Stanislav Malyshev [mailto:stas@zend.com] Sent: Monday, August 27, 2007 9:49 PM To: Dmitry Stogov Cc: 'PHP Internals List' Subject: Re: [PHP-DEV] Namespaces and __autoload()

<?php namespace Foo; throw new Exception; In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to

__autoload() that

say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions.

There's two problems here: 1. On each access to internal class, like Exception, SPL classes, DateTime, reflection classes, etc. - we'd have call to autoload and subsequent disk access, maybe more than one if we have include path. Performance of it would be awful. 2. All libraries having autoloaders would have to rewrite them to support the new mode. I would propose different solution. When we have unresolved unqualified name, we do the following: 1. Check if we already know such class in namespace at compile-time. If so, it's resolved. 2. If not, will be resolved at run-time. 3. At run-time, check if we know such class in namespace now. If yes, it's resolved. 4. If not, check if we know internal class with such name. If yes, it's resolved to internal class. 5. If not, try to autoload this class. If autoloading fails, it's the undefined class error. This rule is a bit more complex, but allows to resolve common cases without extra filesystem accesses and allows to keep autoloader without modification. Comments? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php