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:[EMAIL PROTECTED]
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
