Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)
| From: | Rasmus Lerdorf | Date: | Wed, 19 Jul 2006 01:27:16 +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 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-24609@lists.php.net to get a copy of this message | ||
Steph Fox wrote:
Steph, I think prefixing internal classes is the most userfriendly approach actually as it leaves these top-level names to userspace code and prevents future conflicts. We are talking about classes here, so it isn't like they get typed very often either. You instantiate the class and then name the resulting object yourself with whatever short descriptive variable name you want. It's quite different from the procedural API where you certainly don't want php_if() or php_while() since those are needed all the time. But $foo = new PHPFoo(); $foo->func1(); $foo->func2(); looks perfectly acceptable to me. -RasmusThis is a good solution. 3 extra characters for each class have not hurt spl users (no reports of SPL-related carpal tunnel syndrome yet, right? :). It will make it simple to figure out whether a class is internal (does it start with "Php?") and will eliminate all future debate. I have no qualms renaming the PEAR packages that I maintain that start with PHP_ if this decision is made.Oh please, how is this a good solution? Just think of the users out there for one moment, please?