Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 26 Nov 2005 13:51:36 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <399443266.20051126135136@marcus-boerger.de>
To: Greg Beaver <cellog@php.net>
Cc: internals@lists.php.net
In-Reply-To: <4387AA54.70002@php.net>
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> <4387AA54.70002@php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
From: helly@php.net (Marcus Boerger)

Hello Greg,

Saturday, November 26, 2005, 1:20:36 AM, you wrote:

> Marcus Boerger wrote:
>> Hello Helgi,
>> 
>>   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.

> I absolutely agree with these points.  It is also worth noting that the
> coding standards of prefixing classes were introduced long after
> packages like "Date" existed.  We have a case of a userbase and a
> shifting foundation that is PHP.

> Perhaps the best future of PEAR is to design with those shifting sands
> in mind as more of a primary design concern.  There's plenty of time
> before PHP 6, so we can get this taken care of by then, I think.

> These are just preliminary thoughts, but it is imperative that all PEAR
> classes be tested, and by inference testable, with PHP releases.
> Anything that comes from .php.net should work with PHP, or at least be
> given a chance to fix the problem before the release.  This means a
> tighter integration of PEAR developers and PHP internals, by no means an
> easy task, as is shown by Pierre's tribulations over Date.

> At the least, it would make sense to provide some kind of PEAR-related
> RC cycle for PHP releases.  I will see if I can shake up some ideas on
> how to get PEAR more involved (at least better involved) in the PHP
> release process over on pear-dev and report back.

Very well said. I hope you can do something on the PEAR front. For the PHP
front i am already working on some automatic testing. Once that's done we
will look for a way to bring in PEAR tests into it as well.

Best regards,
 Marcus