Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82171
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54D7CCB5.2020709@lsces.co.uk>
Date: Sun, 08 Feb 2015 20:53:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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> <54D7B267.5000902@gmail.com>
In-Reply-To: <54D7B267.5000902@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dragging the legacy users forward.
From: lester@lsces.co.uk (Lester Caine)

On 08/02/15 19:00, Rowan Collins wrote:
> 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.

Rewriting the the code to make it work is exactly what is taking the
time, but I DID also adopt the standard that e_strict would be required
and up until that time all the code I was involved with ran with
display_errors ON which was a conscious choice to pick up problems that
crept in when they happened rather than having to trawl through hundreds
of log files every few days. Remove 'register_globals' and a site breaks
until such time as  the code is reworked, but that code also needs to be
brought up to a better standard rather than simply hacking the
register_globals and other removed or backwards incompatible problems.

Since a large part of the code I am now supporting I did not write,
simply trying to decipher some of the strange tricks coders used to get
up to is a nightmare, and some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code   in the future.

There are several pages of things that were good practice in PHP5.0 code
which will now give white screens if one tries to run them on a 'good
practice' PHP5.4 setup. Fortunately I think that I've already covered
most of the later problems in trying to make the legacy code clean
e_strict code so switching from 5.4 to 5.6 should not cause a problem,
but I'm not ready to move production beyond 5.4 as yet.

If I was only worried about a couple of sites then things would be
different, but the current catalogue is some 120 different sites some of
which are pigging ASP and I will be glad when I can finally pull them
over to PHP.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk