Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38777
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 208.83.222.18 as permitted sender)
Message-ID: <486FA5FB.1000300@php.net>
Date: Sat, 05 Jul 2008 12:48:59 -0400
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: PHP Developers Mailing List <internals@lists.php.net>, 
 Dmitry Stogov <dmitry@zend.com>,
 stanislav Malyshev <stas@zend.com>
References: <ADD0525F-F900-4F3A-9B76-1ED332CA31E0@pooteeweet.org>
In-Reply-To: <ADD0525F-F900-4F3A-9B76-1ED332CA31E0@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: towards a 5.3 release
From: cellog@php.net (Greg Beaver)

Lukas Kahwe Smith wrote:
> Aloha,
> 
> Since Johannes has been stumped (and therefore not as visible as he 
> would have hoped) with work and 5.3 CVS is already filled brim with 
> awesome new features, I have been approached by several people wondering 
> how we can speed up the process. I have always said I am available to 
> play the secretary to the RM, but in order to ensure that developers 
> have a greater chance of having an RM to talk to, Johannes agreed to 
> move me to co-RM status.

glad to hear it!

> 1) namespaces
> Here we need to make sure that the current state is now in a coherent 
> state. I think Derick still has some issues [3] with the recent change 
> by Greg [4], but even his criticism did not sound all to loud. So I 
> think we are in a good state here?

My recent changes aside, there are still some fubar issues with name 
resolution, and there has been some offlist discussion of ways to fix 
this that have not led to concrete onlist proposals yet.

For those who don't know what I'm talking about, the question is how to 
resolve an unqualified classname inside a namespace.  i.e. this code:

a.php:
<?php
namespace Foo;
throw new Exception('is this Foo::Exception or ::Exception?');
?>

Currently, the above code would throw ::Exception, because if a 
namespaced class does not exist, internal classes are checked before 
autoloading for performance reasons.  However, if we execute this code 
instead:

b.php:
<?php
namespace Foo;
class Exception {}
include 'a.php';
?>

then a.php would throw Foo::Exception.  In other words, depending on 
file inclusion order, classnames can change with current PHP accepted 
practices.  The solution to this is to use each namespaced class explicitly:

a2.php:
<?php
namespace Foo;
use Foo::Exception;
throw new Exception('this is Foo::Exception always');
?>

However, all it takes is one forgotten "use" statement, and a very 
subtle bug could be introduced later.

Taking a step back, let's examine why autoload is not called before 
checking internal classes - it is for performance reasons.  However, 
this performance enhancement causes unpredictable behavior *by default* 
without explicit action.

There is a simple solution, however.  If one changes the name resolution 
to this pseudo-code:

1) check Foo::Exception for existence
2) if not found, try to autoload Foo::Exception
3) if not found, check for ::Exception existence, userspace *or* 
internal (addition of userspace check also fixes other problems raised 
on-list)
4) if not found, fail.

This fixes the logic problem, and re-introduces the performance slowdown 
for internal classes.  FORTUNATELY there is a simple solution to this, 
which is to "use" all global classes:

<?php
namespace Foo;
use ::ArrayIterator;
$a = new ArrayIterator(array(1,2,3));
?>

The above code works exactly the same as:

<?php
namespace Foo;
$a = new ArrayIterator(array(1,2,3));
?>

and short-circuits the name resolution to:

1) check ::ArrayIterator for existence
2) if not found, fail.

To summarize, we should scrap the "performance enhancement" that 
introduces the potential for subtle and dangerous logic errors in name 
resolution because it is still possible to achieve that performance 
enhancement through one-time "use" of internal classnames.

With these changes, namespace classname resolution will be 100% 
deterministic regardless of file load order, it will still be possible 
to override internal classnames with userspace classes, and for the 
ultra-performance hungry, it is still easy to achieve faster classname 
resolution for internal classes.  Win-win.

Greg