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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
