Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
Message-ID: <52E99136.7080605@gmail.com>
Date: Wed, 29 Jan 2014 23:39:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEZPtU6749gD2a9BDzdTQoBPUsPDSspjukZvFw9qwt=Le5Q1zQ@mail.gmail.com>	<52E7D67D.1030308@ajf.me> <CAEZPtU6M3_x7Kv1U8gOAx3L3ZDZxt6UiV8RLxaY3voYUvnoqFw@mail.gmail.com> <52E7F55F.7090801@ajf.me> <52E7FCA2.70009@oracle.com> <52E80A0E.7060408@lsces.co.uk>
In-Reply-To: <52E80A0E.7060408@lsces.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] some thoughts about php 6
From: rowan.collins@gmail.com (Rowan Collins)

On 28/01/2014 19:50, Lester Caine wrote:
> The best comment from that is
>> The solution is clear: build a full compatibility layer, not a 
>> conversion tool, into 3.x that makes 2.x code run without change and 
>> ABRUPTLY stop development on 2.x.

What this basically means, is "maintain backwards compatibility, but 
make it an opt-in feature".

> The only problem is should it run PHP5.2 code, or only PHP5.6? Little 
> things like only supporting e_strict?

No, the biggest problem (apart from implementing and maintaining it!) is 
how to scope this compatibility layer.

If you have to turn it on with an ini setting - which generally means 
for the whole deployment, or at least the whole application - then you 
still have to have an almighty push to upgrade your application before 
turning it off.

What might be more interesting is if it could be limited by namespace, 
or by file, or something like that. Then you could include an entire 
PHP5 library in a project which was otherwise taking advantage of PHP5++ 
features, right down to invoking a different parser if necessary.

I was pondering a similar idea for existing notices - particularly 
E_STRICT, E_DEPRECATED, and E_NOTICE. The code base I work with relies 
on some really old PEAR modules, which we're planning to phase out in 
favour of something else. If we turn up error_reporting, we get a whole 
load of notices from code we're never going to maintain, drowning out 
any useful hints in code that was written last week.

Of course, to truly solve the adoption problem, the compatibility would 
have to be 100%...

-- 
Rowan Collins
[IMSoP]