Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33930
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: <C0D87144-50B3-4C26-BEDF-E5BB93ED1C4A@bitxtender.com>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <475EF175.2030304@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:35:17 +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>
Subject: Re: AW: [PHP-DEV] Namespace resolution
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

Am 11.12.2007 um 21:22 schrieb Stanislav Malyshev:

>> Ah. Yes, that makes perfect sense to me. The logical solution must  
>> be then, however, not to implement namespaces at all, or requiring  
>> code
>
> It's not a solution, it's refusing to solve a problem.

Well, if your answer is that it makes sense this way and that it's not  
gonna be changed because it cannot be implemented without significant  
overhead, then I need to say that it would be better to have no  
namespaces rather than significantly flawed namespaces.


>> 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
>
> If it's "obvious" for you that namespaces are useless, probably you  
> need to give your obviousness-meter a check-up. They were found  
> useful by many people, even if there are things to work out here and  
> there - which happens with each new concept not tested in the field.

They are not useless. They would just be useless


>> 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
>
> There's no such thing as "namespace name for which autoloding is  
> performed". Autoloader receives a full class name, that's it. How  
> this name was created is irrelevant.
>
>> just the autoload functions of currently imported namespaces would  
>> have to be called.
>
> I don't understand what do you mean here, but it doesn't matter,  
> since autoload call on each class access is very bad regardless of  
> how it's implemented internally.

Yes, because you didn't bother to even read what I wrote. I'll explain  
it with an example for you, maybe that helps:

Let's assume we have ten autoloaders. We are, by import, in namespace  
Name::Space. Someone does new DateTime();

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.

However, if it were possible to do this:

spl_autoload_register(array('Name::Space::Ship', 'autoload'),  
'Name::Space');

Then you could would not have to call ten autoloaders, but just those  
registered for the currently imported namespaces. As we've only  
imported "Name::Space", this is just the one I showed above. Class not  
found? Okay, use PHP's DateTime. Overhead gone.


>> 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
>
> "use whatever;" is a no-op. There's even warning about it in the  
> engine.

Stas, really, stop retreating to technical details and making me look  
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.

David