Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
| From: | Derick Rethans | Date: | Tue, 18 Jul 2006 22:41:06 +0000 |
| Subject: | Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h) | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-24573@lists.php.net to get a copy of this message | ||
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