Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105537
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.com>
 <e702a5cc-9567-0591-8f5e-b14aef0766b7@lsces.co.uk> <CAAfnsFU1B61qaPRAh5uNTWMALcV5xmae0Yb1yY9+QaAGLVGx7A@mail.gmail.com>
 <49A4B76C-4C62-4CBE-BA20-FBE56CA29AB0@cschneid.com> <CADyq6sL7m=A=pA1rNBg_CFOoMtfCZn50AfALh9jtLHvn9NRzmw@mail.gmail.com>
 <609E93CF-099B-446C-AD28-04F1D802C9F0@cschneid.com> <000401d4fac8$ae592cf0$0b0b86d0$@roze.lv>
 <CAJHtznz-Dm7ft6qJ6Y6sjnaL4G0cwVVJyakxr_zprhxQzqUkVg@mail.gmail.com>
 <CAFPFaML4QTbtJXLuheGwTTT204vY40TeT5TLEX22oYTNrNJ8Qg@mail.gmail.com>
 <CAJHtznwnbM54uAzStVfAOjUTgEoDr8XpOFCYdVjgrtZfFgrSJw@mail.gmail.com>
 <CAFPFaM+EGh6zZgSdDXo06wdY==Fujm1JFWFO88EmvggC-fdFJA@mail.gmail.com>
 <CAJHtznztD-UOSoeSApvTMidNo6z20MUWNNBRUW84_JxM0fRq-g@mail.gmail.com>
 <alpine.DEB.2.21.1904301800070.9606@singlemalt.home.derickrethans.nl>
 <CAJHtznzSOo1Xbmu3N9C_GEo6woDC0STVR_nVjUCusT65dfPe=A@mail.gmail.com>
 <CAAfnsFWogfyZ=X07EOAZ6V4vSKw89K01WGnddRF=zRP9-FBsdg@mail.gmail.com> <961cee8e-8185-b7b2-2b51-838946d2c7d2@gmail.com>
In-Reply-To: <961cee8e-8185-b7b2-2b51-838946d2c7d2@gmail.com>
Date: Wed, 1 May 2019 02:19:27 +0200
Message-ID: <CAAfnsFUhMKf1YYuT1eCF65yfX+FjNAcr_MyAiPM-fiPawTKDLQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, Derick Rethans <derick@php.net>, "G. P. B." <george.banyard@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: peterkokot@gmail.com (Peter Kokot)

On Wed, 1 May 2019 at 00:56, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
> Hi!
>
> > Worth noting another inconsistency here that we've missed. PHP 7.4 has
> > introduced many BC breaks actually already. Without this level of
> > problems:
>
> Exactly, without. There's a difference between removing an unmaintained
> extension which is barely used and setting people up for displaying
> their sources if they use slightly outdated libraries. And there's a
> difference between explicitly making a decision and not even bothering
> to discuss this mammoth of a BC break until the vote is finished. So to
> me it's more like "elephant in the room" scenario - we've got a process
> failure here. We are on the course to correct it, but it's a failure
> nevertheless.

It is a BC break nevertheless no matter how much time it takes to
change the code. The level of the impact cannot be measured like this.
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then good
(for example, BC breaks allowed in major releases, minor releases
including only new features etc). Upgrading PHP version would be then
a breeze probably but very complex to maintain the code in the repo
(at least according to the release cycles of 5+ years to get to a
major version). However, I'm not sure I'm seeing such direction or
anyone expressing it to do this at least according to many here and
even this discussion. Because, from what I think here more is that
we're discussing how to keep the short tags forever and how to remove
them as soon as possible. There is a difference in what people want
here. And majority of those not in favour of the removal in PHP 8,
want them to have forever and basically want to change the issue of
removing the tags in the first place. I haven't seen any step forward
from this point yet and what kind of a different removal strategy
(compared to Nikita's suggestion) would work.

> > The deprecation in PHP 7.4 (or even if there wouldn't be any
> > deprecation here at all) and removal of some short tags in PHP 8 is
> > the least of users problems I think.
>
> You mean wddx removal is much bigger problem for users than the
> potential for their code to be sent out instead of executed? If so, we
> must be living in very different words, because for me the former is a
> blip on the margin of the radar and the latter is a "world on fire, do
> not upgrade under any circumstances" scenario. I could easily ignore the
> former and I wouldn't dare to upgrade any production for the latter
> without long process of verification that would 100% ensure there's no
> bad tags hiding in any code, any dependency, any library, etc. Maybe
> it's what the RFC authors want, but it's certainly a giant difference in
> BC impact.

I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear definition of
what is opening PHP tag.

-- 
Peter Kokot