The only scripts that would break (far from "trillions") here would be
those where you had a space-less ternary statement comparing two
constants (NOT namespace constants -- they don't even exist yet), as
in the following case:
define('foo','odd');
define('bar','even');
$var = rand() % 2 == 1 ? foo:bar;
It seems like the solution here would be to give constants a higher
priority in the symbol table than namespaces, though I certainly don't
have the knowledge of the code base to make any conclusion as to how
difficult that might be.
Personally, I'd rather have namespaces with stupid symbols than no
namespaces, but my preference would definitely be either single or
double colons, as would most users, I wager, since that's probably the
most common namespace symbol in use amongst popular languages that
support namespaces. The argument that PHP isn't <insert language>
sounds good on paper, but in practice the language still has to
conform to some basic expectations when it comes to syntax. There's a
reason why the -> operator was chosen for member access, there's a
reason why || and && are used for logic operators, there's a reason
why the dollar sign is used to declare variables, and there's a reason
why a semicolon is used to end statements. NS:Class vs NS::Class vs
NS\Class is largely insignificant at the end of the day, but it's
better to try to stick to some common symbols that programmers of
different disciplines will be able to pick up on. PHP isn't taught in
most universities, and making things even harder for people to pick it
up seems counter-intuitive.
People who's "php coding" is limited to editing config files for
vbulletin and xcart certainly couldn't care less about namespaces, but
those of us who are writing applications and middleware, as well as
complex sites, would find the functionality tremendously useful. I'm
tired of walking on glass worrying about naming conflicts.
It's easy to say "well, name your classes sensibly!", but the reality
is that it's totally non-sensical to ask a developer to prefix THEIR
classes in application code. We're not psychics, we can't guess that
one day some core developer is going to create a Date class that will
cause fatal errors in our code. It's not just Date, of course -- it's
every common name out there. Should I not name a class
FrontController, because the SPL might implement one later? The list
goes on and on. The only real solution is to use NON-sensible class
names (I prefer greek dieties) to guarantee future-proofness.
Virtually every major application out there, from vbulletin to
MediaWiki to phpAdsNew has had a major naming conflict with another
application. Having silly dangly things on every classname / function
name gets annoying (at best), and is a giant waste of time. We want
short, concise function and class names, not
"my_application_html_clean_sessions()" Being able to import a
namespace that you need with aliases (or even just into the global
namespace) is a HUGE plus. This is especially true since PHP itself
doesn't even really follow a naming convention (htmlentities vs
html_entity_decode, isset vs. is_int and so on and so forth). If the
core doesn't follow conventions, how can you expect userland code to?
Even if the namespace patch is something that has to be done as an
extension, I'd be happy to see it in place. It's a fairly easy task to
get users to add --with-namespaces to their configure scripts, but
it's much more difficult to ask them to try to use diff and patch to
maintain their own builds (much less hand-edit C code).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
