Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31948
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <46D351F5.8080806@chiaraquartet.net>
Date: Mon, 27 Aug 2007 17:36:37 -0500
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Dmitry Stogov <dmitry@zend.com>, 
 'PHP Internals List' <internals@lists.php.net>
References: <000f01c7e871$9be827e0$6e02a8c0@thinkpad> <46D30EA2.7080406@zend.com>
In-Reply-To: <46D30EA2.7080406@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Namespaces and __autoload()
From: greg@chiaraquartet.net (Gregory Beaver)

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