Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33934
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: internals@lists.php.net
Message-ID: <31696FA6-ADC3-4853-A5AE-23FA16750B3D@bitxtender.com>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <475F01B1.8090407@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 23:08:43 +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> <7F9E1E02-FF89-474B-9E94-007747B3637A@bitxtender.com> <475EF175.2030304@zend.com> <C0D87144-50B3-4C26-BEDF-E5BB93ED1C4A@bitxtender.com> <475F01B1.8090407@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 22:31 schrieb Stanislav Malyshev:

>> You would now have to go through all ten autoloaders before you can  
>> decide that no userspace class DateTime exists in any namespace,  
>> and thus the PHP internal class DateTime may be used.
>
> Even one autoloader is bad enough to not even have to consider the  
> case of ten autoloaders. Remember, autoloader is filesystem access.  
> Filesystem access on each class mention is a disaster.
>
>> like a fool when you're tired of coming up with arguments. You very  
>> well know I meant "import". Reply to the suggestion in a respectful  
>> manner, or give it a miss.
>
> I'm afraid I still do not understand what did you mean. Could you  
> explain in more detail?

Sure. My basic idea was that since the issue we're talking about can  
only occur either in namespaced code, or in code that uses namespaced  
components, there would not be any backwards compatibility problem  
with something like:

import Name::Space;
// only stuff from Name::Space available, no PHP internal stuff
import __php__;
// now PHP's classes are loaded, too.
$d = new DateTime(); // this loads __php__'s DateTime, since the first  
existance check gives that one, so no autoloading is ever performed,  
even if there is a Name::Space::DateTime class.

Now, assuming that someone wants to use PHP stuff _and_ Name::Space  
stuff of the same name, they can do import __php__ as __php__; (or  
import Name::Space as NS and then new NS::DateTime()) for either  
statement to work around that. In any case, it would never introduce  
issues. My statement 'doing a "use __php__" is not a tall  
order' (which means it's not asking much from the developer to do  
that) from one of the previous mails was referring to just that. Think  
of other languages with namespace/package concepts. If you want to use  
java's date/time features, you need to do some kind of import  
java.util.blah stuff, too. I don't think that PHP's internal stuff  
needs to be magically available. We can force developers to explicitly  
request access to it.

Did that explanation help? :)

David