Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41926
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <C8.60.32680.1E10F194@pb1.pair.com>
To: internals@lists.php.net
Followup-To: php.internals
Lines: 34
Date: Sat, 15 Nov 2008 18:07:40 +0100
References: <49188698.1050505@grudl.com> <49188BD0.9090100@kukulich.net> <4918A3F8.4070809@chiaraquartet.net> <4919A9BD.2020703@grudl.com> <491DE402.4000600@chiaraquartet.net> <72.BB.07308.119ED194@pb1.pair.com> <491E0297.20108@chiaraquartet.net> <3C719ED4B1154E88ADA3A76835B98809@pc>
Organization: CrystalPoint
User-Agent: KNode/0.99.01
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Subject: Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
From: m.kurzyna@crystalpoint.pl (Marcin Kurzyna)

"Stan Vassilev | FM" wrote:

> For me the only way to make it clear to both humans and parsers alike is
> the filepath semantics, in all places, including use. It's not perfect,
> there's no completely problem-free solution, but "prepend \ for absolute
> path" is able to become muscle memory, while other mixed solutions I've
> seen are more confusing and require more thinking: "wait in this context
> what was what?".

My point exactly. This was a real pain in the ass while converting from old
to new resolution rules (though I now this is a one-time example).

However i was explaining the new resolution rules to my co-workers recently 
and it was aparent the context dependant resolution isn't clear, while 
understanding: "it's always relative to current namespace" is simple and 
easy. Also most people are familiar with filepath semantics so there is a 
obvious point of reference (and confusion when it's not consistent).


> But this introduces a new keyword: nameof, which could clash with
> function/class/constant "nameof" in existing source code. I could suggest
[...]
> But it's definitely in-your-face issue while using namespaced code.

I'm not shure how big of a problem "nameof" clashing would be, however a way 
to get fully qualified name is a nessesity in my opinion - i strugle with 
this in my framework too. 

Gregs suggestion of __NAMESPACE__ concatenated solution (if i understand it 
correctly) isn't one accualy because __NAMESPACE__ resolves to current 
namespace; and "typeof" might (and probably usually will) be used on aliased 
classes not nessecerely from current namespace.

m.