Very good points Kevin since I was accused of wanting to turn PHP into C++ earlier just for not liking the \ separator. I suppose the person that selected the -> object operator had the same intentions :)
Bob > -----Original Message----- > From: Kevin Brown [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 26, 2005 1:36 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] 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). > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
