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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
