Re: Re: PEAR::Date broken (Was: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/date php_date.c php_date.h)

From: Date: Wed, 19 Jul 2006 20:19:43 +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 5  Groups: php.internals 
Request: Send a blank email to internals+get-24725@lists.php.net to get a copy of this message
Hello Greg, this whole thread unfortunatley shows that nobody is reading our provided documentation, see excerpt from CODING_STANDARDS: [7] Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CampelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension). Good: 'Curl' 'FooBar' Bad: 'foobar' 'foo_bar' I changed that long ago....actuall more than half a year ago. And the examples are there since over two years: marcus@zaphod /usr/src/PHP_5_2 $ cvs annotate CODING_STANDARDS|grep -A14 '\[7\] Cla' Annotations for CODING_STANDARDS *************** 1.33 (helly 26-Nov-05): [7] Classes should be given descriptive names. Avoid using abbreviations where 1.33 (helly 26-Nov-05): possible. Each word in the class name should start with a capital letter, 1.33 (helly 26-Nov-05): without underscore delimiters (CampelCaps starting with a capital letter). 1.33 (helly 26-Nov-05): The class name should be prefixed with the name of the 'parent set' (e.g. 1.33 (helly 26-Nov-05): the name of the extension). 1.26 (derick 23-May-03): 1.26 (derick 23-May-03): Good: 1.26 (derick 23-May-03): 'Curl' 1.33 (helly 26-Nov-05): 'FooBar' 1.26 (derick 23-May-03): 1.26 (derick 23-May-03): Bad: 1.26 (derick 23-May-03): 'foobar' 1.26 (derick 23-May-03): 'foo_bar' 1.35 (helly 22-Dec-05): 1.1 (zeev 07-Apr-99): Syntax and indentation If you have any further suggestion i'd be happy to discuss it and place it in the file as well. best regards marcus Wednesday, July 19, 2006, 9:57:34 PM, you wrote: > Steph Fox wrote: >>> Please, just make a clear decision, stick to it, and tell us what it is, >>> we will adapt our coding standards to whatever is decided. >> >> >>> Either: >>> >>> 1) internals declares all top-level classes, use an unprefixed name (no >>> _) at your own risk >>> 2) internals grabs PHP or Php as a prefix. >> >> >> I think both. I think top-level classes should belong to PHP _anyway_ >> and PHP 6, if it indeed brings namespacing for classes, should take that >> option and use it. You have to understand that I'm taking a very >> long-term view here; I see PHP 5 as a transitional period, and PHP 4 as >> something that needs to be supported _as far as we can and for as long >> as we can_. >> >>> Choose. >> >> >> Why do you think there has to be a choice made there? What else should >> be using PHP as a namespace prefix? > Perhaps I'm not being clear. PHP has done an excellent job of defining > "don't touch this" areas before. For instance: > __magic methods are off limits. > The reason the "Date" dilemma has started is because php has not defined > a way that internal classes should be named. After Marcus's email, I > see that this will be impossible, but perhaps it would work to say this: > "PHP will not use an underscore _ in any future internal class names. > Userspace classes with no underscores may conflict with an internal > class. Exceptions include mysqli blah blah blah" > Would this work for everyone? > PEAR is all about underscores in class names, especially since all new > classes since about 2003 are required to have them. Take a peek, the > classes that don't have them are more than 4 years old (DB, MDB, Date, > PEAR, etc.) > As long as we know this is a rule, we can solve the Date dilemma quite > easily. For instance, a 3-line solution: > in file "PEAR/Date.php": > class PEAR_Date { > // ..put the code here from the old Date class > } > in file "Date.php": > require_once 'PEAR/Date.php'; > class Date extends PEAR_Date { > } > This way, users who wish to use an older PHP version need not change > code, and new users can use the PEAR_Date class. The point is, you > *must* make a decision so we can honor it. If you simply claim all > possible future class names, it makes it difficult to create userspace > classes to fill in the holes in PHP that will work in multiple PHP versions. Best regards, Marcus

« previous php.internals (#24725) next »