Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106283
MIME-Version: 1.0
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
 <28a9ccf7-f5be-eb1e-999a-06170beeed4b@gmail.com> <CAF+90c_rm3UcGzV4FhLs_-VzFvnE0Uq0m1e_WO5B5uQ+J8+A5g@mail.gmail.com>
 <b6cb48e4-05f2-d55e-f1d5-95c7efc983e9@gmail.com> <5d37a85f.1c69fb81.9e2eb.29d0SMTPIN_ADDED_MISSING@mx.google.com>
 <182e4bf7-05f0-5dec-0e4d-4071cb1249a8@gmail.com> <CAFPFaM+8rJkfbjSU_bdWHT4szNaBZtKm0cE8Vu-LaSpck=bUdQ@mail.gmail.com>
In-Reply-To: <CAFPFaM+8rJkfbjSU_bdWHT4szNaBZtKm0cE8Vu-LaSpck=bUdQ@mail.gmail.com>
Date: Wed, 24 Jul 2019 09:56:35 -0400
Message-ID: <CAPKYkKz_r1_DAocA7K8CsW6mJuFLA1VTkMb=yEzdAhMGHsEGew@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	Zeev Suraski <zeev@php.net>
Content-Type: multipart/alternative; boundary="0000000000001d9505058e6dae75"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000001d9505058e6dae75
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 24, 2019 at 9:27 AM G. P. B. <george.banyard@gmail.com> wrote:

>  On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
> > Hi!
> >
> > > Due to the controversy after the initial vote on the Deprecate PHP's
> > Short
> > > Open Tag RFC [1] here is a new RFC to deprecate them written with the
> > help
> > > of Nikita Popov <nikic@php.net>.
> >
> > Could you please explain what has changed since the last time we
> > discussed it that makes it necessary to bring the second RFC on the same
> > topic?
> >
>
> On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
> > Hi!
> >
> > > V2 remedies that by maintaining default INI behaviour, as well as
> > > nullifying the possibility of code / data leaks by throwing a compiler
> > > exception if <? is encountered (and enabled), thus denying the VM an
> > > opportunity to execute a file which contains potentially leaky code.
> >
> > Oh, I thought it was already agreed upon... I thought the RFC somehow
> > modifies upon that. I think parse error for 8.x would be acceptable.
> >
> > --
> > Stas Malyshev
> > smalyshev@gmail.com
> >
>
> Nothing, this is a courtesy vote as the implementation proposed in this RFC
> is the one which would be used to implement the previous RFC even though
> it is not the one proposed initially.
>
> Now if we can all agree that this can land without needing to go through
> this
> whole process I think everybody wins: we all don't need to spend time on
> this,
> it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
> happen because of some problems with the wincache extension from what
> I'm seeing) which puts less strain on them IMHO.
> Because I'm pretty sure I'm one of the most annoyed to need to go through
> this process once again.
> Is this going to happen? Probably not so here we are.
>
> On Wed, 24 Jul 2019 at 05:51, <vsuraski@gmail.com> wrote:
>
> > - [Short tags]  You need to purposely turn it on in your own deployment -
> > people and companies who use it use it exclusively for internal purposes.
> >
>
> This is just plain wrong since PHP 5.4 as it is enabled by default and you
> need to actively turn it OFF as which can be seen on https://3v4l.org [1]
> as it doesn't use any INI configuration files. Now as stated in the RFC:
>
> > Currently the <? short open tag is controlled by the short_open_tag
>
> ini setting. This ini setting is *enabled* by default (if no ini files is
> > used),
>
> but *disabled* in both php.ini-development and php.ini-production.
>
>
> which is probably why most of us - and most users - think that it needs to
> be implicitly enabled.
>
>
> I've modified the RFC to state the removal of the short_open-tags in PHP
> 9.0.
>
> Best regards
>
> George P. Banyard
>
> [1] https://3v4l.org/kKDI9
>

I was very vocal in regards to the first RFC (both before and after the
vote) so I figured I'd should say something about this RFC.

My overall opinion remains the same: There is still no justification for
removing short tags that justifies the BC break. I pretty much agree with
everything Zeev said in his email. That being said, I think this RFC
handles the deprecation process much better. My objections to the previous
RFC were two-fold: 1.) benefits didn't outweigh harms and 2.)
deprecation/removal path was dangerous and harmful.

I still think #1 applies to this RFC. I do not think #2 does. While I agree
with some others that the it might be better to postpone the decision about
the ultimate removal to a later date, I don't think slating it for 9.0 is
that big of a deal. I think it also gives people much more time to adapt
than previous road maps.

-- 
Chase Peeler
chasepeeler@gmail.com

--0000000000001d9505058e6dae75--