Hello Kevin,
bla!
Saturday, November 26, 2005, 10:35:51 PM, you wrote:
> 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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
