Steph Fox wrote:
Rasmus, I'm sorry but I can't agree with you. When we get namespacing it'll make perfect sense to have PHP::Foo(). Until then, it makes no sense whatsoever to me to mess about with plain names for root classes.

Since the early days of PHP4 everybody is using the plain names for userland classes. And these greatly outnumber the core classes. That's why it makes sense to think twice about it. Break things if necessary, but don't break things without a good reason and without a bigger plan.

We aren't breaking 'tousands of apps out there' unless someone doesn't bother to read the upgrade guide and happens to have not prefixed their own classes. And if in that situation, all the user needs to do is search and replace, and all _we_ need to do is offer support for that replacement that will work in PHP 4 as well as in PHP 5.2 and beyond.

There seems to be agreement on
a) There should be namespace support for core classes at some point
b) Only very few plain name core classes will be introduced before that

Based on that I still don't understand why you insist on making every PHP user's (and there are a few more than PHP devs out there) life harder than necessary by forcing them to prefix their classes. You don't enforce them to prefix their variable or method names either, do you?

Sure, you can call it DateTime (and something like DateTimezone) now and I wouldn't riot but only if no further plain name core classes are going to be introduced after that (because this discussion would start all over again).

As opposed to what you are saying I would find a search and replace for PhpDate => Php:Date much easier than searching for arbitratry userland class names and replacing them with a prefixed version now just for the theoretical case that some new core class with a name collision might be added later. And you wouldn't even need to replace PhpDate in my book because two simple aliases would be enough to handle that.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to