This is a good solution. 3 extra characters for each class have not hurt spl users (no reports of SPL-related carpal tunnel syndrome yet, right? :). It will make it simple to figure out whether a class is internal (does it start with "Php?") and will eliminate all future debate. I have no qualms renaming the PEAR packages that I maintain that start with PHP_ if this decision is made.
Oh please, how is this a good solution? Just think of the users out there for one moment, please?
In terms of PEAR, please stop discussing PEAR in such a negative light when it comes to this decision of class naming. The internal decision has nothing to do with PEAR, and we who bust our ass maintaining and managing PEAR do not force anything on you, and more to the point, *cannot* force anything.
I never intended to blast PEAR. I was accused of doing so purely because I was under the total misapprehension that PEAR already had namespacing as part of its CS, and PEAR::Date had violated that. I was wrong. So be it. Sorry!
The truth is that PEAR is the *only* large code project using PHP that pays any attention to the decisions on the internals list, and so we (independently) offer opinions here occasionally. There are several ways of handling this problem, but we first need to know what the hell we can do to avoid it in the future.
Agreed.
For several years now PEAR has forced prefixing (since about 2003) of all new proposals. What we haven't done is forced all existing users to rename their classes.
Maybe enforcing that would have been wise. I think the only way out of the impasse now is to have two versions of those classes that aren't already namespaced, which is why I made the offer I made earlier. To do anything else would involve messing up users who need to upgrade PEAR but don't want to upgrade PHP.
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?
Greg
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
