Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41146
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48F772CD.80600@zend.com>
Date: Thu, 16 Oct 2008 09:58:53 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Greg Beaver <greg@chiaraquartet.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <48F653FF.5010106@chiaraquartet.net> <48F75FA1.7020505@zend.com> <0C55B977-3835-4CB0-A23B-8AA684B71C18@pooteeweet.org>
In-Reply-To: <0C55B977-3835-4CB0-A23B-8AA684B71C18@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] my last attempt at sanity with namespaces
From: stas@zend.com (Stanislav Malyshev)

Hi!

> 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"?

I can't tell what Greg meant for him, but for me the problem exists 
regardless of the class being internal or not.

> imho the thing is, that the person who is developing a namespace that is 
> autoloadable knows this (or should know this), as a result its his 
> obligation to either trigger the autoload via a "use" statement or by 
> prepending the current namespace name to the class name.

Namespaces aren't autoloadable, classes are. But what I see happening is 
that people would start converting excisting code, and since they are 
human they will inevitable forget or miss class here and there. And it 
would work, and pass all tests, and look fine and dandy on the outside - 
but under the water it would contain the performance bomb of 
non-cacheable exhaustive autoload search. It is a big disservice for our 
users to put them into this situation where you need to be an expert to 
even notice where the problem is - especially that we *already* know the 
problem exists and we *know* how to fix it. Why not just fix it?

> imho the main use for namespaced code will be libraries and not 
> application level code (with the exception that some people have 
> mentioned that they might want to stick their templates in namespaces), 
> so i think this burden is legit, since most of us spend their time 
> writing application level code and not library code (sorry full time 
> ezc/zf developers).

That doesn't matter - applications would contain private libraries as 
part of the function, which would contain namespaces. Look at big 
application like Magento - there's definitely potential for huge use of 
namespaces inside the application. Namespaces aren't by no means limited 
to off-the-shelf libraries - I see much use of them precisely in the 
custom code in big projects.

But the more important issue here is that we KNOW there's a problem. Why 
should we look for reasons to diminish its importance when we have a fix 
for it, which most of the target audience would accept?

> so imho the solution is "none of the above". the solution is that 
> however wants to make his namespaced code to be autoloadable must make 
> sure he explicitly triggeres the autoloading.

There's no such thing as "autoloadable" or "not autoloadable" code in 
PHP now. So I'm afraid I miss what you trying to tell - do you say we 
should stay with what we have now? Or do something else?
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com