Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <531C21A9.30002@lsces.co.uk>
References: <CAMauByXxg877TEhQiSWSRkJR-wYvP+pm=mLHK9=9N05t2SiUmw@mail.gmail.com>
 <03CFE6C6-0742-4928-BD2B-E9C920E9246A@ajf.me> <CAMauByUz=rUYwdMcZi5+_wSUBcV_KRiMZs0foL5ZyDxwKxh-6Q@mail.gmail.com>
 <29BDF40C-562D-4943-877B-70701335D3AA@ajf.me> <CAGAGxbbVuMcH+bYJuw20NUScuOTbxqfC6m=G2JsnEKQyYvtByQ@mail.gmail.com>
 <CAMauByVW0Lk9=_3aXGW6DSSVm5a8C5p95R2LWA+x8NBovVbMBA@mail.gmail.com>
 <CAL0xaBE4LpweEVnw+uXKun8OtSqoVMnzi2BaWAeanSkP_eG+Qg@mail.gmail.com>
 <CAMauByX6V6s_GaNKuyrSF7ZGrGGCfY=9kzyn-QzPnGc26sfe1Q@mail.gmail.com>
 <B875101A-6CF1-443C-8F17-5D895CB2D66B@rouvenwessling.de> <531C21A9.30002@lsces.co.uk>
Date: Tue, 11 Mar 2014 11:43:57 +0100
Message-ID: <CAMUwpuR1mtntx+aoS3A6i0wvEVQi6FJpsX8qh_xu5uAO6yToRw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136776a160fad04f4526806
Subject: Re: [PHP-DEV] Idea: ifdef-like feature to ease userland BC
From: jpauli@php.net (Julien Pauli)

--001a1136776a160fad04f4526806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 9, 2014 at 9:09 AM, Lester Caine <lester@lsces.co.uk> wrote:

> Rouven We=DFling wrote:
>
>> I really don't want to come across as hostile, but this seems poorly
>> thought out. We all like to play with the new shiny, but I don't see suc=
h a
>> feature benefitting the quality of the code out there.
>>
>
> I don't mind coming across 'hostile' ...
> The idea that we need to add additional hacks to get around the fact that
> some 'shiny new features' simply don't sit well in the vast majority of
> legacy code. If there is an existing codebase designed for a previous
> version of PHP, simply hacking in bits that might improve things for some
> later users is just wrong full stop! To get the best out of many new
> features the code needs to be redesigned properly!
>
> If one is designing to support older versions then one simply does not us=
e
> the new features. e_strict requires enough structural changes that
> something like this would not work anyway, so there will be many places
> where even this hack will stop legacy versions of PHP running the code?


I'm not in favour of such thing.

- It adds very complex preprocessor code, making the overall PHP code hard
to read and understand. Leave preprocessor to C.

- OPCache already does many things to try to improve the generated code at
compilation, so that execution OPCodes are optimized depending on the
environment. There still has many ways to improve things in here though.

- The more we add features to support multiple PHP version, the more slow
people will migrate. You want to absolutely use "yield" and pretty nice new
syntax feature of PHP ? Simply drop your support for older PHP versions.
That's what well-known-frameworks did with 5.3 (mainly to benefit from
anonymous functions and namespaces), and that's what they'll have to do for
next PHP versions.

Julien.P

--001a1136776a160fad04f4526806--