Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26537
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)
Message-ID: <12.E7.40419.07F58554@pb1.pair.com>
Date: Mon, 13 Nov 2006 14:04:44 +0200
To: Sean Coates <sean@caedmon.net>
Cc: internals <internals@lists.php.net>
In-Reply-To: <4554AE0D.4080600@caedmon.net>
References: <4554AE0D.4080600@caedmon.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
From: zeev@zend.com (Zeev Suraski)

Sean,

I think there are fair chances we'll introduce a very simplistic 
namespaces capability in PHP 6.  It's pretty clear it will not have 
the notion of imports, and will be very much focused on classes (as 
opposed to functions and variables).  In fact, I think you can very 
much imagine them as being a new way of writing a class name - just 
imagine you could specify a single colon (or whatever) in your class name.

Anything beyond that is going to result in a significant slowdown of 
the execution engine *and* open a can of warms regarding scoping and 
symbol resolution.  Just to clarify what Rasmus said (which is indeed 
what was agreed for PHP 6) - we will add namespaces to PHP 6 if we 
can find a good way of defining their semantics in the PHP spirit as 
well as an acceptable way to implement it.  Those two reasons very 
much limit what we can or cannot do with namespaces in PHP, 
especially the first one.

Zeev

At 18:51 10/11/2006, Sean Coates wrote:
>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-code-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