Derick Rethans wrote:
Using generic names for core functionality in the global name space
is a bad
thing, no matter how convenient the name might be. That's a lesson
PHP has
learned for function names quite a while ago, let's not repeat the same
mistake for class names.
No no, the core reserves the right to name whatever they want, it's
the userland code that is responsible for prefixing their classes.
True, but where part of the PHP project has already adopted that name,
doesn't it make sense to assume that they have a first priority to this.
This seems to fall back to the discussion a few months back about how
much BC breakage people wanted to cause in 5.1/6 in any case. I thought
this was resolved back then, but evidently not.
It'd seem to me that there's two options - just say that there'll be
breakage[0] like this throughout the 5/5.1 release process and don't get
anybody moving to it or to keep major breaking for major revisions - the
way every other largescale opensource project works (and does so for a
damn good reason).
I'd personally far rather that such a break came in 5.1 over 5.1.1,
though I still don't think a change which has such a major impact over
such a large portion of the userbase is a good plan for a minor release
(much less a maintainance release like 5.1.1); after all, there's been
some 259,000 downloads of pear's date class and I'd argue there's a
substantial amount of developers with their own date class outside of
that group. You're effectively talking about hitting 300,000-500,000
developers with a massive change on a minor release. You talk about
doing things the 'right' way often - well that's just plain wrong.
[0] Ok, I know it's not really breaking anything within php - but it's
breaking a lot of apps.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
