Re: Re: PHP 5.1 (Or How to break tousands of apps out there)

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).