Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82199
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
Message-ID: <54D7F9BD.9080407@gmail.com>
Date: Mon, 09 Feb 2015 00:05:17 +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> <54D7B267.5000902@gmail.com> <54D7CCB5.2020709@lsces.co.uk>
In-Reply-To: <54D7CCB5.2020709@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 20:53, Lester Caine wrote:
> 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

OK, so that's your choice - you have deliberately set yourself a higher 
bar than PHP has, in order to end up with better code. Good for you.

I can also imagine that setting that high bar may make it harder to make 
the kind of compromises that are inevitable when writing code intended 
to run on multiple versions simultaneously.

> 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.

If all you're worried about is running on multiple versions of PHP, the 
manual includes a one-liner to emulate register_globals. Again, 
reworking it is a good idea, but not something that PHP actually forces 
on you.


> 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.

If you're writing code that you know will be hard to maintain in the 
future, you're doing something wrong. If by slavishly following a style 
guide you've ended up with a poor architecture, you need a better style 
guide, or a better understanding of why those styles are preferred.

Alternatively, I may have misunderstood that sentence, in which case I 
apologise in advance.


> 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.

Maybe, but most of them can be replaced by code which runs fine on both 
versions. It may not be the best code you could write if you knew you 
could rely on new features, but it works.

For instance, when the preg_replace "/e" modifier is removed, it will 
still be possible to write code that uses preg_replace_callback() with 
the almost-as-ugly create_function() instead of a real anonymous 
function. That gives you compatibility all the way back to 5.0, and all 
the way forward to 7.0; it's also slightly less likely to be a security 
hole, so you're improving your code base by doing it. If you decide that 
good code is more important than cross-compatibility, you can go ahead 
and use the 5.3+ closure syntax instead, but no decision made on this 
list will have forced that on you.

Regards,

-- 
Rowan Collins
[IMSoP]