Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48F77525.6060507@chiaraquartet.net>
Date: Thu, 16 Oct 2008 12:08:53 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Stanislav Malyshev <stas@zend.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <48F653FF.5010106@chiaraquartet.net> <48F75FA1.7020505@zend.com> <0C55B977-3835-4CB0-A23B-8AA684B71C18@pooteeweet.org> <48F772ED.3090001@chiaraquartet.net> <E627B8FB-49C5-4EFB-8B02-2E15C50E9F72@pooteeweet.org>
In-Reply-To: <E627B8FB-49C5-4EFB-8B02-2E15C50E9F72@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] my last attempt at sanity with namespaces
From: greg@chiaraquartet.net (Greg Beaver)

Lukas Kahwe Smith wrote:
>
> On 16.10.2008, at 18:59, Greg Beaver wrote:
>
>> Lukas Kahwe Smith wrote:
>>>
>>> On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
>>>
>>>> B. There's a huge problem with this proposal which you seem
>>>> consistently to ignore despite all my attempts to explain it. Failed
>>>> autoload on each call is BAD. Very bad. It is not cacheable, it leads
>>>> to multiple disk accesses and it is absolutely undetectable to the
>>>> PHP user without the use of special tools. So making all existing
>>>> code contain this performance bomb unless you rewrite it is very bad.
>>>> It's better to have this code fail and provide simple script to fix
>>>> it in automatic fashion. The fix you propose - writing use's - is not
>>>> enough because as you noted later inertia would make users not to use
>>>> this code and thus have huge performance hit - which most of them
>>>> even wouldn't know where it came from.
>>>
>>> first up i am a bit irritated by the use of the term "internal class",
>>> i guess you both mean to say "class in the global namespaces"?
>> no, we are talking about classes built into PHP such as Exception or
>> ArrayObject, not userspace classes without namespace.
>
> why are they different?
> also since they apparently are different, how does this all work when
> its not about an internal class, but a global useland class? as in
> what if in your example it would not be the Exception class, but a
> class called FooBar, which is defined in the global namespace in some
> userland code? 

That's a great question, and I didn't realize it was a confusion, so
I'll try to answer it clearly.

The purpose behind resolution rules in namespaces is to make it easiest
to access

1) stuff with the same namespace prefix
2) internal functions, constants, and classes built into PHP

So, there is no chance for conflict with this code:

foo.php:
<?php
function __autoload($class){include $class . '.php';}
class Foobar{}
?>

<?php
namespace bar;
include 'foo.php';
$a = new Foobar; // this tries to autoload bar::Foobar if internal class
Foobar does not exist
?>

To force resolution to userspace Foobar, all you need add is:

<?php
use ::Foobar;
?>

Greg