Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <A0F1443687494829B378016521494E15@pc>
To: <internals@lists.php.net>
References: <49188698.1050505@grudl.com> <49188BD0.9090100@kukulich.net> <4918A3F8.4070809@chiaraquartet.net> <4918AFE1.70506@grudl.com>
Date: Tue, 11 Nov 2008 00:11:40 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-2";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

> I understand this new behaviour is same as using "relative paths", but 
> there is a common best practise to not make dependencies form topper 
> namespaces to deeper ones.
> So it is rare to have class Company\Software\Base extending 
> Company\Software\Web\Forms\Control (i.e. Base extends Web\Forms\Control), 
> and it is common have class Company\Software\Web\Forms\Control extending 
> Company\Software\Base.
>
> So in real world it means that nearly every usage of "partially qualified 
> indentifiers" (Sub\Object) have to be written with preceding backslash.
>
> David Grudl

Can you please point us to an example describing this best practice?

Aside from this, the problem is: scopes. In other languages we don't have 
preceding separators and those conflicts hence don't exist, since with 
scopes, if a name doesn't exist in the local scope, it's automatically 
bubbled up until it goes right back to the global scope.

In PHP nothing bubbles, hence this doesn't work. We have just one exception 
to this, with global functions in local space which "bubble up" to global 
even without the prefix (which I believe will come to bite us later on).

However there's still one more issue, "use" clauses only understand full 
symbol names, which causes yet another inconsistency:

namespace foo;
use bar\baz as bar_baz;

$a = new bar\baz(); //instantiates class with absolute path "foo\bar\baz"
$b = new bar_baz(); //instantiates class absolute path "bar\baz"

In fact, use doesn't even know what the prefix would mean:

use \bar\baz; // parse error

So it has to be decided which way the system goes to avoid confusion and 
bugs IMO.

Regards, Stan Vassilev