Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82159
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
Message-ID: <54D7B267.5000902@gmail.com>
Date: Sun, 08 Feb 2015 19:00:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54D606D2.7030102@lsces.co.uk> <54D74BFF.3070604@b1-systems.de> <54D756D4.20006@lsces.co.uk>
In-Reply-To: <54D756D4.20006@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dragging the legacy users forward.
From: rowan.collins@gmail.com (Rowan Collins)

On 08/02/2015 12:30, Lester Caine wrote:
> Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
> is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
> doing between 5.4 and 7. The code has to be reworked ... so what ever
> anybody says PHP5 .4*IS*  PHP6 in terms of major breaks.

We have a single code base happily running on 5.2, 5.3, 5.4, and I think 
even 5.5, so it is definitely possible with some code bases. There were 
a few pieces that had to be changed to work right under 5.3 and 5.4, but 
none for which the new solution didn't also work under 5.2 (or, at 
least, for which a compromise didn't exist which worked under both). 
Call-time pass-by-reference was all over the place, for instance, but 
rarely actually needed, and if it was, replacing it with a 
pass-by-reference declaration would leave you with something working 
fine under 5.2.

It's frustrating not being able to use new features when you need to 
support an outdated installation, and finding third-party libraries 
which support old versions of PHP can be tricky. 5.3 was the big 
breaking point there, because although we didn't refactor our code to 
use namespaces, libraries quickly came to be written with them (which is 
a good thing) so automatically have that as a minimum version requirement.

The biggest problem with keeping userland code cross-version compatible 
is usually syntax - behaviours and standard functions can, if it's 
really necessary, be worked around by checking PHP_VERSION, or "if ( ! 
function_exists('blah') { function blah { ... } }". But because there's 
no equivalent of a C pre-processor, you can't work around syntax which 
wasn't valid on older versions, other than by not using it (it would 
have been lovely to include closures in code which was simply 
unreachable on 5.2 hosts, but if 5.2 needed to parse that file, it was 
impossible).

Clearly, your experience is different; perhaps some specific examples of 
the problems which forced you to fork the codebase, rather than adapt it 
into a cross-compatible state, would help people look out for the same 
situation arising in future.

Regards,

-- 
Rowan Collins
[IMSoP]