Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20344
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <01.D8.11378.05EC6834@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 25 Nov 2005 09:41:46 +0100
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
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>	<pan.2005.11.25.07.40.45.515129@php.net> <1086017308.20051125091648@marcus-boerger.de>
In-Reply-To: <1086017308.20051125091648@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
From: lsmith@php.net (Lukas Smith)

Marcus Boerger wrote:

>   obviously one problem is that PEAR does ignore coding standards. Classes
> should be prefixed in both pear and core. And neither Date nor File is in
> any way prefixed. In th end all we see here is that we want namespaces asap.

Err, how are we supposed to prefix PEAR::Date?

PEAR_Date?
Date_Date?
Lala_Date?

I guess only the first one is somewhat valid proposal.

Anyways it makes absolute sense to use the best most clear class names 
when we add functionality currently missing in PHP. Just as well it 
makes sense for php core to do the same thing.

The problem is just that PEAR is not part of the php development cycle. 
So whatever API we come up with is totally ignored by php core. This may 
be because the PEAR API sucks. It may also be caused by the fact that 
usually our implementation will probably be written for a previous PHP 
version.

In a perfect world we would define an API, implement it in PEAR as a 
testbed for interest and if we find its popular and there are 
significant performance improvements to expect from an implementation in 
C we take that API and implement it in C.

However I do not see this happening ever. So I do not see a point in 
PEAR packages claiming away nice and clear names from php core. We 
should either cooperate on the API level or just have php core superseed 
PEAR stuff.

PEAR then goes and fixes whatever breakage occurs. What however would be 
nice is some advance notice. And where is the entry in the upgrading 
guide? Oh and for the record if there is a PEAR class by the name of 
Date you can be sure that there is a class by the name of Date as well.

So in conclusion its needlessly messy. I am sure other projects than 
PEAR also have a Date class. Maybe we need to teach our users (including 
PEAR) that they should simply stick to prefixing everything with 3-4 
letter combinations (maybe even offer a central place to register them, 
like we should do in the PEAR channel listing - 
http://pear.php.net/channels/).

regards,
Lukas