On Tue, 18 Jul 2006, Steph Fox wrote: > Yep, that's a fair point. But at the same time, PEAR should be namespacing > their classes - and in fact the date class in PEAR is breaking PEAR's own > coding standards in that respect. Why should classes internal to PHP have to > care about a rogue PEAR class? Why shouldn't the rogue PEAR class rather be > made to comply with the coding standards, or even (watching pigs fly by here) > release a version that does so, which would at least offer people the choice > when upgrading to PHP 5.2 from earlier versions? It's only a > search-and-replace when a class is renamed, it's not a major problem when > you're having to do that for other things anyway to upgrade. It's not like > anyone's asking people to rewrite code altogether - it's way less problematic > than the reference fixes were. All it needs is a mention in the upgrade guide: > 'If you have a class named 'date' in your codebase you will need to prefix it. > If you use PEAR::Date you will need to switch over to Pear_Date and adapt > calls to the Date class from within your code accordingly; there are no other > changes in the PEAR code base, and it will still run under both PHP 4 and PHP > 5'. > > It simply doesn't make sense to me to have a plain, simple, descriptive name > for an existing extension that can't be used as that extension's class name > because PEAR already used it. The rest of core PHP doesn't suffer in this way, > so why should ext/date?
Amen. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
