Re: Re: PHP 5.1 (Or How to break tousands of apps out there)

From: 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

« previous php.internals (#20393) next »