Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20169
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <6.2.3.4.2.20051118113030.03382ab0@localhost>
Date: Fri, 18 Nov 2005 11:33:46 -0800
To: Jani Taskinen <sniper@iki.fi>
Cc: truth@proposaltech.com,internals@lists.php.net
In-Reply-To: <Pine.LNX.4.61.0511180959210.4255@arfg.argcubovn.sv>
References: <437B530A.5050105@prohost.org>
	<437CF6B4.5080207@web.de>
	<437CF943.7090800@lerdorf.com>
	<437D0D08.8060805@web.de>
	<437D0E22.7080006@lerdorf.com>
	<437D11B7.7090102@web.de>
	<437D1361.5080504@prohost.org>
	<1132274666.8441.175.camel@notebook>
	<6.2.3.4.2.20051117165150.028458b0@localhost>
	<Pine.LNX.4.61.0511180959210.4255@arfg.argcubovn.sv>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Upgrading php
From: andi@zend.com (Andi Gutmans)

Yep that's definitely a good start. The two things we might want to 
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6 comes a long.
b) Have a script that automatically makes the changes that can be 
done without human intervention.

We had something similar to (a) and (b) when we moved people from 
PHP/FI 2 to PHP 3 as there were some significant differences. That 
said, it's not always simple because you might need to have to reuse 
the scanner/parser and a simple PHP script might not be enough.

Hopefully, as we get closer to PHP 6 there will be people who have 
time to invest in this.
Most important thing at this point, is to keep the upgrading docs 
(which will be first released with 5.1) in sync with the changes, so 
that when the time comes with PHP 6, it'll be easy to translate the 
docs to such a script, without forgetting half the stuff that was changed.

Andi

At 12:06 AM 11/18/2005, Jani Taskinen wrote:
>On Thu, 17 Nov 2005, Andi Gutmans wrote:
>
>>I'm hoping that in future we can provide better tools for upgrading 
>>in between versions. Both from an auto-conversion perspective and 
>>just scanning the code statically and printing out warnings on what 
>>code to check. Coupled with better upgrading docs I think we'd 
>>improve the current situation significantly.
>
>     We already have the scanner:
>
># php -derror_reporting=4095 -l script_to_check.php
>
>Strict Standards: Usage of {} to access string offsets is deprecated and
>will be removed in PHP 6 in t.php on line 6
>No syntax errors detected in t.php
>
>     With a simple shell script you can create a list of files having
>     any errors/warnings/notices/strict.. :)
>
>     At work we use a syntax checker script run whenever we commit files
>     to our CVS repository to catch any errors early..this reminded me to
>     fix that script to catch notices and such too. :)
>
>     --Jani