Namespaces and __autoload()

Stanislav Malyshev wrote:

<?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.

This is a problem, agreed.

2. All libraries having autoloaders would have to rewrite them to
   support the new mode.

This is not an issue - won't they have to support
Class::Names::Like::This anyways? Backwards compatibility has already
been broken.

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.

The problem is that with this autoload technique this code now throws an
Exception rather than a Foo::Exception:

Foo/Exception.php:
<?php
namespace Foo;
class Exception extends ::Exception {}
?>

Foo/Something.php:
<?php
namespace Foo;
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}

class Something
{
function __construct($param)
{
if ($param == 3) {
throw new Exception('oops');
}
}
}
$a = new Something(3);
?>

This would mean that all naming conflicts with internal classes must
have a different import or be fully qualified.

However, I wonder if using an import would be a clever way to get around
the problem?

Foo/Something.php:
<?php
namespace Foo;
import Foo::Exception;
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}

class Something
{
function __construct($param)
{
if ($param == 3) {
throw new Exception('oops');
}
}
}
$a = new Something(3);
?>

As I understand it, this would make the file act as if we had written it
like:

Foo/Something.php:
<?php
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}

class Foo::Something
{
function __construct($param)
{
if ($param == 3) {
throw new Foo::Exception('oops');
}
}
}
$a = new Foo::Something(3);
?>

If this is indeed the case, then it would satisfy my concerns with the
patch and would simply be up to the documentation team to document this
gotcha.

Greg

Why don't we add an optional second argument to __autoload() that
receives the fully qualified namespace name of the class that should
be autoloaded? That doesn't break BC and it prevents conflicts.

David

Am 27.08.2007 um 19:49 schrieb Stanislav Malyshev:

<?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