Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26512
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <99.20.32592.5ED45554@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 10 Nov 2006 23:13:22 -0500
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
References: <4554AE0D.4080600@caedmon.net>
In-Reply-To: <4554AE0D.4080600@caedmon.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Namespaces in PHP 6 - ++$take
From: jrhernandez05@gmail.com (Jessie Hernandez)

Hello,

I haven't had time to work on my patch, but thinking about this some 
more, I'm convinced namespaces should only contain classes. The only 
problem that was present when permitting functions/constants to be 
inside namespaces was the ambiguity in ternary expressions. By just 
supporting classes inside namespaces, this issue would go away. Besides, 
I'll dare say that most, if not all, the developers who want namespaces 
will only group classes with it anyways,

Also, by only supporting classes, we can use ":" instead of the long 
":::" separator and everyone would be happy.

Last I checked, the only things that were pending on my patch were some 
scoping issues which I had to fix. These are listed below. Once these 
are done, the patch can be formally proposed. If anyone wants to take a 
look at the patch so far and/or work on the remaining issues below, let 
me know and I'll either post the patch or email it.


Pending:

1) The extends clause should resolve imported class names.

import class ns:DateBase;

namespace ns{ class Date extends DateBase{} }

2) To access a global symbol, use global:<class_name> syntax.

3) Type hints should also consider imported classes.

4) When an import is done (with alias or not), and a global class with 
that same name exists, what is the desired behavior? Error? Global takes 
precedence?



Regards,

Jessie Hernandez


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