Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40391
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.128 cause and error)
Message-ID: <48C5F612.6090001@lsces.co.uk>
Date: Tue, 09 Sep 2008 05:05:38 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: 5.3 Backwards Compatibility
From: lester@lsces.co.uk (Lester Caine)

While I have loaded 5.3.? changing any of my existing code base to remove 
warnings is not likely to happen any time soon since compatibility with users 
who are still running older versions of PHP still needs to be maintained.

I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be 
currently the only reference to changes? But where do I find the detail on how 
things ARE currently implemented such as namespace and (fingers down throat) 
goto?

Another major concern here since maintaining BC with *PHP4* is still an 
unfortunate current requirement in the field is what happens when PEAR 
actually uses namespace and other 5.3 only features. HOW will we manage 
accessing versions of PEAR that are compatible with our active codebase and so 
ensure that we have compatible sets of packages?

Personally I can't stand the CURRENT problems that is caused by not knowing 
which version of a PEAR extension users actually have and in order to ensure a 
COMPATIBLE version, but in future will the PEAR installer pick up a correct 
version for the copy of PHP actually being run?

I get the distinct impression that those pushing for PHP5.3 are simply not 
making a good case for many of us to even want to follow them down that path? 
It almost feels like this is a DIFFERENT path to the main stream of PHP6 which 
many of us are much more desperate to be testing in the field, which seems to 
have become an ignored backwater? Key elements which have been flagged to PHP6 
( such as BIGINT ) are on hold while new concepts which were not part of the 
PHP6 reoadmap have been forced through? Since current hardware *IS* 64 bit, 
actually handling 64 bit numbers properly would be nice :)

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php