Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106288
MIME-Version: 1.0
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
 <5C8F3403-2972-467A-AFA5-347C09E5FA73@gmail.com> <CAF+90c-oN=_rjFyq4HbMCwyq=xhDopnF5ETy_oViL_DbjD=2oQ@mail.gmail.com>
 <CAPg3XxLg21WbLLPLoNvXfTrw-wv6uhuVSG=r=QHs11-9iBnNeA@mail.gmail.com> <CAF+90c9bcnHK1xeWX2pPQMsrdr3Hjb3xRhrm0iA4kr-0SKXcXQ@mail.gmail.com>
In-Reply-To: <CAF+90c9bcnHK1xeWX2pPQMsrdr3Hjb3xRhrm0iA4kr-0SKXcXQ@mail.gmail.com>
Date: Wed, 24 Jul 2019 22:40:26 +0100
Message-ID: <CAPg3XxJ3MB657Q1SB0LcHfYDETXPJXBcnEovV0G=fDcPixYvtw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a677e3058e7427f5"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: petercowburn@gmail.com (Peter Cowburn)

--000000000000a677e3058e7427f5
Content-Type: text/plain; charset="UTF-8"

On Wed, 24 Jul 2019 at 13:21, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn <petercowburn@gmail.com>
> wrote:
>
>>
>>
>> On Tue, 23 Jul 2019 at 22:03, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>
>>> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins <rowan.collins@gmail.com>
>>> wrote:
>>>
>>> > On 23 July 2019 18:54:48 BST, "G. P. B." <george.banyard@gmail.com>
>>> wrote:
>>> > >The only point of contention of this RFC that I potentially see is the
>>> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP
>>> 8.0
>>> > >instead of it being removed in PHP 9 after it having had a whole major
>>> > >version release cycle.
>>> >
>>> > Given that you've already predicted that this will be controversial,
>>> could
>>> > you provide some rationale for it? Unless there's a major burden in
>>> > maintaining the parser error behaviour for a few years, waiting for the
>>> > next major version would seem both safer and more in line with official
>>> > versioning policy.
>>> >
>>> > As with deprecation itself, any violation of the "no breaking changes"
>>> > rule, however slight, should have an explicit justification. If I had a
>>> > vote, any RFC omitting such a justification would receive an automatic
>>> "no"
>>> > from me.
>>> >
>>>
>>> I agree. I don't think there's a pressing need to do the "full removal"
>>> in
>>> PHP 8.1 in particular, so it makes more sense to this in the next major
>>> version (9.0), as usual.
>>>
>>> Nikita
>>>
>>
>> Would you (George, Nikita) consider removing the details about the
>> eventual removal of the feature from this RFC?  We can run with the error
>> for a bunch of releases / years, and see what happens.  I don't see why we
>> should necessarily decide now on something that might be 5 years or more
>> away.
>>
>
> I don't see a benefit in leaving this open-ended and prefer to have a
> fixed timeline for this. The full removal in 9.0 is already very, very
> conservative. Using short tags will have produced a fatal error for a whole
> major version at that point. If necessary the question can be reevaluated
> at that time, but the burden of proof must be on the people arguing an
> additional delay, not the other way around.
>

Hypothetically, it can be re-evaluated sooner, particularly if "everyone"
in the PHP ecosystem appears to respond very well once the deprecation and
error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be
a point being made if/when that discussion comes along.  My point is that
the removal release/date, in my opinion, is a detail that we don't need to
be concerned with right now and it's just adding noise.  You disagree, and
that's totally okay.


>
> Nikita
>

--000000000000a677e3058e7427f5--