Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26475
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
To: "'Sean Coates'" <sean@caedmon.net>,
	"'internals'" <internals@lists.php.net>
Date: Fri, 10 Nov 2006 09:49:13 -0800
Message-ID: <010101c704f0$8a7df080$6800a8c0@zend.2k>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <4554AE0D.4080600@caedmon.net>
Thread-Index: AccE6ITI9dnaEpaFT6KbL7q7Xiv50AAB6n3g
Subject: RE: [PHP-DEV] Namespaces in PHP 6 - ++$take
From: andi@zend.com ("Andi Gutmans")
References: <4554AE0D.4080600@caedmon.net>

Too long of an email to read :) but just wanted to give a heads-up that we
haven't forgotten about this (it's on the PHP 6 list).
We'll try and come with a proposal in the coming weeks with a way to do it.

> -----Original Message-----
> From: Sean Coates [mailto:sean@caedmon.net] 
> Sent: Friday, November 10, 2006 8:51 AM
> To: internals
> Subject: [PHP-DEV] Namespaces in PHP 6 - ++$take
> 
> Hello all,
> 
> A number of factors have come together to prompt me to 
> possibly commit mailing-list-suicide by re-opening the 
> namespace issue.
> 
> Last week at Zendcon, a number of PHP developers/community 
> members chatted about namespaces in PHP 6. That chat was the 
> prime motivator for this email, but the recent (be they 
> misguided) complaints about symbol collisions in DateTime, as 
> well as blog entries such as Jeff Moore's on maintainability [1].
> 
> None of us chatting seemed to be able to come up with a good 
> reason we don't yet have namespaces, other than frustration 
> (the last time we discussed this, the thread became VERY long 
> and drawn out), indecision (we couldn't seem to come to a 
> decision on a suitable operator), and complacency.
> 
> The way I see it is that implementing namespaces is a 
> technical hurdle, and the reasons we haven't jumped it are 
> political, not technical.
> 
> So, let's deal with these 3 problems:
> 
> Frustration: this thread will likely get long. Please avoid 
> long-winded explanation of why you don't like the looks of 
> "\" or how ":::" is hard to type. If you have something 
> relevant to say, it's probably already been said [2][3]. 
> Please review the archives.
> 
> Indecision: We couldn't decide on "\" or ":::". What this 
> comes down to is that "\" is the only remaining operator that 
> can be typed in a single keystroke on us_en keyboards. The 
> other choice was ":::". I, for one, am OK with either 
> operator. I think someone with appropriate (social) karma 
> needs to simply commit to one or the other, and we'll make 
> do... we always do.
> 
> Complacency: Most of the time, I'm happy to maintain the 
> status quo in PHP-land. However, the lack of namespaces is 
> causing more trouble than its absence is preventing. I think 
> most PHP users would agree that namespaces are a welcome 
> addition, and without them, PHP suffers. Let's take this in 
> small steps and implement optional userspace namespacing.
> There's no need to dive head-first into this and make 
> dramatic moves like putting all core functions into a PHP 
> namespace. Baby steps, please.
> 
> And, in conclusion (thanks for reading this far; I've 
> certainly exceeded the average non-code-paste post length, a 
> few times over), remember that the core devs discussed this 
> in Paris, last year [4]. They didn't come to a conclusion 
> (note the use of "if"), though.
> 
> Let's settle this political issue, please, so we can get on 
> to solving the technical issues that will inevitably crop up.
> 
> S
> 
> [1]
> http://www.procata.com/blog/archives/2006/11/09/why-is-php-cod
> e-considered-hard-to-maintain/
> [2] http://beeblex.com/lists/index.php/php.internals/20586
> [3] http://beeblex.com/lists/index.php/php.internals/17484
> [4] http://php.net/~derick/meeting-notes.html#name-spaces
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To 
> unsubscribe, visit: http://www.php.net/unsub.php
>