Re: Re: PHP 5.1 (Or How to break tousands of apps out there)
| From: | Ilia Alshanetsky | Date: | Fri, 25 Nov 2005 12:52:39 +0000 |
| Subject: | Re: Re: PHP 5.1 (Or How to break tousands of apps out there) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-20393@lists.php.net to get a copy of this message | ||
Christian Schneider wrote:
> As has been pointed out before this isn't only a PEAR problem: Every
> single application out there defining a Date class has to be changed if
> the core adds a class with the same name.
Defining classes/function with generic names will always be a problem as
they may end up conflicting with same constructs from other libraries or
PHP itself.
> Is this common? One of our running gags here is that every project ends
> up adding its own set of date formating/conversion functions/classes at
> some point. So unless people are prefixing all local classes there is a
> rather good chance of having a class named Date in quite some projects.
To design future proof code projects for the most part prefix all their
functions/classes to prevent naming conflicts.
> Section [7] of CODING_STANDARDS Naming Conventions states that "The
> class name should be prefixed with the name of the 'parent set'" but at
> the same time lists "Curl" as good. Now my question is whether the
> prefixing should be enforced (at least when a common name like Date is
> used)?
It makes little sense to have a class called curl_curl, when it comes to
functions the coding standard applied and all functions have a prefix.
Ilia