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