Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4B034CE9.7020207@chiaraquartet.net>
Date: Sat, 21 Nov 2009 10:54:57 +0100
Cc: Kalle Sommer Nielsen <kalle@php.net>,
 PHP 'Internals' Wonderland <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D78B8293-7261-424A-AB89-694706FFED24@pooteeweet.org>
References: <2dedb8a0911161713m5d8c3d3dma5013968d11f586f@mail.gmail.com> <4B034CE9.7020207@chiaraquartet.net>
To: Greg Beaver <greg@chiaraquartet.net>
Subject: Re: [PHP-DEV] Re: PHP6's future
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 18.11.2009, at 02:24, Greg Beaver wrote:

> What needs to happen is for developers to focus on finding problems
> highlighted by failing .phpt tests.  The most complex extension that
> needs some loving is the SPL extension.  I would hazard a guess that =
if
> these .phpt tests are fixed, a large number of roadblocks will =
disappear.

AFAIK PDO is also in a very broken state, though independently of PHP6 I =
am currently hoping to revitalize PDO development, which might also lead =
to building up the necessary resources/skills to get HEAD fixed up too.

Anyways, to me it boils down to 2-3 people really putting in lots of =
time to move things forward and to build up momentum again. We all know =
how it feels to add stuff onto something that is fairly broken and who's =
future is not yet certain. We all hate wasting time, so those 2-3 people =
will mostly reassure that time spend on HEAD is not wasted.

In this light when I last brought up this topic. Not sure if on IRC or =
the mailinglist it turned out that 3 different approaches were seen by =
people. Again who ever takes the helm on this will hopefully realign the =
community behind just one:
1) similar to Kalle's suggestion, clean up HEAD
2) make HEAD a proof of concept branch, turn 5_3 into HEAD, reimplement =
just the features we in the end found useful from HEAD
3) make HEAD a proof of concept branch, turn 5_3 into HEAD, implement a =
string class (both a unicode and a non unicode version) along the lines =
of the intl extension to bring unicode functionality to PHP but in a way =
that lets people easily switch between unicode aware strings.

I think I remember that 2) got the least support. Ilia was the main one =
argueing in favor of 3) and Derick was very much pro 1). I am putting =
this out there not because I am looking forward to a lengthy discussion =
on this, but more because I feel that who ever takes on this task should =
know that there are different opinions on how to best proceed. In the =
end however I think that who ever does the work will probably get the =
biggest say in how things play out ..

regards,
Lukas Kahwe Smith
mls@pooteeweet.org