John Coggeshall wrote:
On Wed, 2006-07-19 at 03:29 +0200, 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. 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.
I agree completely. As I said in a previous post, adoption of PHP 5 is
still gaining momentum and most development being done with it is on new
apps more then upgrading of existing ones by a huge margin. Faced with
this, it makes much more sense to break BC now by naming classes Foo()
and Bar() instead of PHPFoo() and PHPBar()... when forward compatibility
dictates that PHP::Foo() and PHP::Bar() will be the accepted naming
convention.
But having PHPFoo does not in any way prevent PHP::Foo() in a future
version. Not namespacing it in 5.2 and then namespacing it in 6 means
we break stuff for one version for no reason. The "screw you guys, you
should namespaced your stuff" argument is the least userfriendly
approach we could possibly take here and doesn't buy us anything longterm.
I can see Andrei's argument for the iterator stuff where you do actually
have to type it often, but his identifiers are already unlikely to clash
and we could probably make an exception there.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
