Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36816
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain eenterphace.org from 212.227.92.30 cause and error)
Message-ID: <5D0C3386-C2BC-4086-87BB-806E2350B373@eenterphace.org>
To: internals@lists.php.net
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sat, 5 Apr 2008 21:57:05 +0200
Subject: namespace implementation (irritating warning and autoload)
From: jr@eenterphace.org (Julian Reich)

Hi,

I recently started porting an application to PHP 5.3.

1. While testing the new namespace implementation I noticed the  
following:

<?php
namespace Test1;
function fooBar() { echo 'Test1::fooBar()' . PHP_EOL; }

namespace Test2;
use Test1;
Test1::fooBar();

Executing the code above results in a warning: "The use statement with  
non-compound name 'Test1' has no effect in [...]".
I understand the rationale behind this warning but it simply isn't  
true: omitting the use statement results in a fatal error: "Class  
'Test2::Test1' not found in [...]".

Since the following code executes without warning or error I think the  
code above (without use statement) should also execute just fine.

<?php
namespace Test1::Test2;
function fooBar() { echo 'Test1::Test2::fooBar()' . PHP_EOL; }

namespace Test3;
Test1::Test2::fooBar();

But I'm not quite sure about the warning (about the non-compound use  
statement): I think the warning should either be dropped or its  
statement should be fulfilled.


2. I'm sorry for bringing this up again: The current name resolution  
order makes using the namespace feature in conjunction with  
autoloading less usable and somewhat error prone.

    a. To avoid that internal classes introduced to PHP somewhen in  
the future break my app I've to add a number of use statements that  
would not be necessary otherwise.
        So to be on the safe side one has to
           i.   "use" all classes from the current namespace which is  
annoying and  especially in bigger projects one might easily forget to  
"use" classes when making changes
           ii.  use exactly one file per namespace (this might work  
well especially with few classes per namespace that are mostly used  
together,
                 but one can easily think of a lot of situations you  
want to load just the classes that are really needed and in the end  
this is what autoload is for)
           iii. avoid the usage of autoload

    b. Applications might behave differently when packaged
           i.  one class per file using autoload (without "use"-ing  
classes from the  current namespace)
           ii. all classes in one file

    c. Implementors of autoloaders can keep the performance hit to a  
minimum using some kind of caching.

I think the current resolution order is a WTF-factor especially for  
unexperienced users or users coming from other languages.

I know that the above arguments might have been already on this list  
but I couldn't find some definitive decision to keep the current name  
resolution order. If I've missed that I'm sorry for the noise.


Regards,
Julian Reich