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