Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20358 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7135 invoked by uid 1010); 25 Nov 2005 10:33:01 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 7059 invoked from network); 25 Nov 2005 10:32:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2005 10:32:59 -0000 X-Host-Fingerprint: 195.226.6.9 darkcity.gna.ch Linux 2.4/2.6 Received: from ([195.226.6.9:47099] helo=darkcity.gna.ch) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 05/33-56276-BA2E6834 for ; Fri, 25 Nov 2005 05:08:43 -0500 Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id 9E0B813B844; Fri, 25 Nov 2005 11:08:39 +0100 (CET) Received: from unknown by localhost (amavisd-new, unix socket) id client-XXpNlsrz; Fri, 25 Nov 2005 11:08:38 +0100 (CET) Received: by darkcity.gna.ch (Postfix, from userid 65534) id 2BC7413B843; Fri, 25 Nov 2005 11:08:38 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on darkcity.gna.ch X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.1.0 Received: from [192.168.1.44] (217-162-173-187.dclient.hispeed.ch [217.162.173.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTP id 003A213B82C; Fri, 25 Nov 2005 11:08:36 +0100 (CET) Message-ID: <4386E355.7020901@cschneid.com> Date: Fri, 25 Nov 2005 11:11:33 +0100 User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukas Smith Cc: Marcus Boerger , PHP Developers Mailing List References: <7.0.0.16.2.20051124161240.0573e640@zend.com> <20051125034515.6fefa4e2@localhost.localdomain> <43867C6C.2010209@prohost.org> <20051125040950.26305e08@localhost.localdomain> <43869FC5.4060708@lerdorf.com> <20051125075501.79718ee6@localhost.localdomain> <1132903004.9936.25.camel@localhost.localdomain> <1086017308.20051125091648@marcus-boerger.de> <01.D8.11378.05EC6834@pb1.pair.com> <1946534082.20051125100920@marcus-boerger.de> <4386D5C6.8040802@php.net> In-Reply-To: <4386D5C6.8040802@php.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gna.ch Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) From: cschneid@cschneid.com (Christian Schneider) Lukas Smith wrote: > Marcus Boerger wrote: >> That conclusion means stay with date in ext/date and have pear learn the >> lesson by making the same mistake in core. Once again the only >> solution is >> namespacing. > > indeed. > though this "mistake" applies to all of PEAR at this point .. 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. 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. 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)? Or a) am I missing something b) is it the core developers' opinion that core classes have the right of way? - Chris