Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33928
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
Cc: Matthias Pigulla <mp@webfactory.de>,
 Sam Barrow <sam@sambarrow.com>,
 internals@lists.php.net
Message-ID: <7F9E1E02-FF89-474B-9E94-007747B3637A@bitxtender.com>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <475ED038.3080004@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Tue, 11 Dec 2007 21:15:00 +0100
References: <11970653983080000@9866357972520000.9866341568840000> <475BDDF1.7040605@ctindustries.net> <1723341090.20071210220025@marcus-boerger.de> <1197323296.3922.5.camel@sbarrow-desktop> <00A2E2156BEE8446A81C8881AE117F199A0715@companyweb> <A5519084-2CBA-40F4-BDAB-96036428DB17@bitxtender.com> <475ED038.3080004@zend.com>
Subject: Re: AW: [PHP-DEV] Namespace resolution
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

Am 11.12.2007 um 19:00 schrieb Stanislav Malyshev:

>> The problem I see with that is that if I have an application that  
>> uses a 3rd-party library which does not use namespaces, I need to  
>> use ::LibClass everywhere. Until they switch to namespaces - then I  
>> need to touch hundreds and thousands lines of code. If LibClass  
>> were looked up in the global namespace, too, I could simply add the  
>> appropriate import statements at the top of each file.
>
> But also it means that namespaced library would be influenced by any  
> use code around, which was exactly the thing we tried to avoid.
>
>> Anyways, the process you described seems flawed in another fashion:  
>> It looks up a class in the namespace first, then an internal php  
>> class, then it tries an autoload. That does not make sense. Lets  
>> say I run some
>
> Actually, it does :)
>
>> code as you described, and there is a class C(), but it's not been  
>> autoloaded yet. The internal class C is used. Then, later, the  
>> autoloading of A::B::C() is somehow forced. Now, if the same code  
>> runs again, a different class is used. That sounds like nonsense.
>
> Not, it's not nonsense - try to find other way that allows  
> overriding internal class names and doesn't force exhaustive  
> autoload search on each access to internal class - and you'll  
> understand why it makes sense.

Ah. Yes, that makes perfect sense to me. The logical solution must be  
then, however, not to implement namespaces at all, or requiring code  
that is either namespaced or has imported a namespace to do sth like  
"use __php__;", as others suggested last week. I understand the reason  
for the behavior from an implementational standpoint, but I think it  
really is obvious that such a namespace solution would be completely  
useless, as it would not be possible under any circumstances to  
provide code that works in a reliable fashion.

Or, as an alternative, introduce an optional third argument to  
spl_autoload_register where people can give a namespace name for which  
the autoloading should be performed. That would cut down overhead  
since just the autoload functions of currently imported namespaces  
would have to be called.

I don't really think, though, that doing something like use __php__;  
is a tall order, is it? It would only be necessary for those that  
consume namespaces in their code via "use" statements, hence no BC  
break.

- David