Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105385
MIME-Version: 1.0
References: <CAFPFaMJEn=gjk5jAAxR2bF=4Mt3r0FJCm6mbOCReOmyybtAkkg@mail.gmail.com>
 <CAOv67gsiva80KEhw7D2N2qKCz0gZvza30EDL7SZoJRPFsGoROA@mail.gmail.com>
 <0ec42fa9-77d1-a203-8425-e72fdd5071f3@korulczyk.pl> <06473788-a34b-f041-36e6-31d19d8dda4c@cubiclesoft.com>
 <59cafbfb-2bb0-468c-458f-74bcac780e0f@korulczyk.pl> <004c01d4f09f$880ac320$98204960$@roze.lv>
 <CAFPFaM+QwXpm-mfwRtbT2sPB_C-9wvPELVTV5dHvizgmfUjMnw@mail.gmail.com>
 <004401d4faa3$60f83700$22e8a500$@gmail.com> <2f922f17-bc7c-313a-8f77-122e861995be@lsces.co.uk>
 <CAPKYkKyS4A_zQO3OEqqv+LOrG5cPLjGqUEXonsQeA_jcE=69Gg@mail.gmail.com>
 <38D18C20-F297-457A-8BF3-089FFDC8FB3B@koalephant.com> <CAPKYkKzmzE4EpZ7U0ifLME2NWxry5aiWGSNf_qY1vts952cTRA@mail.gmail.com>
 <301BACB1-86FF-4315-9D99-D17A2FDC7F27@koalephant.com> <CAPKYkKw6WGNJpGWzzZVkPkNMAmnkO2iUh-Ssmq0w+jHUG4eaAA@mail.gmail.com>
 <CAJvSBVMV+BnMUMNASUUiVaRgFN_vtmP5ZR0TPe6mjxX6UUS1eA@mail.gmail.com>
In-Reply-To: <CAJvSBVMV+BnMUMNASUUiVaRgFN_vtmP5ZR0TPe6mjxX6UUS1eA@mail.gmail.com>
Date: Wed, 24 Apr 2019 12:06:46 -0400
Message-ID: <CAPKYkKxYARd30q0c0_dLt31nvKM7EAKpJjoXW2SDwupD9AwhhQ@mail.gmail.com>
To: Peter Bowyer <reywob@php.net>
Cc: Stephen Reay <php-lists@koalephant.com>, Lester Caine <lester@lsces.co.uk>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001bf514058748e4ec"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000001bf514058748e4ec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 24, 2019 at 12:04 PM Peter Bowyer <reywob@php.net> wrote:

> Surely the time for vocal opposition was _before_ voting closed?
>
> And I raised my opposition multiple times. That included one email where =
I
laid out a case for why each reason listed for the RFC did not justify the
major BC break. No one ever responded to even one of those points.


> Peter
>
> On Wed, 24 Apr 2019 at 16:51, Chase Peeler <chasepeeler@gmail.com> wrote:
>
>> On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay <php-lists@koalephant.com>
>> wrote:
>>
>> >
>> > > On 24 Apr 2019, at 22:16, Chase Peeler <chasepeeler@gmail.com> wrote=
:
>> > >
>> > >
>> > >
>> > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <
>> php-lists@koalephant.com
>> > <mailto:php-lists@koalephant.com>> wrote:
>> > >
>> > > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com
>> <mailto:
>> > chasepeeler@gmail.com>> wrote:
>> > > >
>> > > > If I get started now, maybe I can have everything fixed by the tim=
e
>> > 8.1 is
>> > > > released.
>> > >
>> > >
>> > > Two characters less than this sentence of yours is a 1-liner find/se=
d
>> > script to replace all `<? ` with `<?php `.
>> > > Would you really feel confident doing a blind find/replace on 6,000+
>> > instances?
>> >
>> > It=E2=80=99s hardly =E2=80=9Cblind=E2=80=9D. This is what version cont=
rol is for. You make a
>> > change, and then either view the diff locally, and/or commit/push it,
>> and
>> > ask others to help review the diff.
>> >
>> > I literally just ran the script referenced above on a client project,
>> > eyeballed the diff, and committed the changes it made to a branch. Onc=
e
>> I=E2=80=99m
>> > not in the middle of anything I=E2=80=99ll review it again and then me=
rge it.
>> >
>> > How big of a project? How many changes? You really think 6,787 changes
>> among 1,656 files can just be eyeballed?
>>
>>
>> > >
>> > > what about <?if ... `<? ` wouldn't match that. I have instances of
>> that
>> > in my code, though.
>> >
>> > So change the pattern to replace `<?` followed by anything except an
>> > equals sign.
>> >
>> > <?if =3D> <?phpif wouldn't work. It would have to be <? that is not pa=
rt
>> of
>> string (inside quotes, heredoc, etc). Even that could be a legitimate
>> case,
>> though, if something is using eval, god forbid. '<? ' can be a straight
>> replacement with '<?php' but anything else '<?(?!php)' gets replaced wit=
h
>> '<?php '
>>
>>
>> > >
>> > > What if I utilize a 3rd party library that, while no longer support,
>> > works fine, but is now broken for no other reason than the fact that <=
?
>> is
>> > no longer supported? Whether I should be using that library or not is
>> > irrelevant. The fact is, I am, and the fact that I won't be able to us=
e
>> it
>> > in 8.0 is a barrier to me upgrading.
>> > >
>> >
>> > You do the same thing as if the library had a security issue or some
>> other
>> > bug. If it=E2=80=99s unsupported, you have to support it, or you have =
to find a
>> > replacement. It=E2=80=99s not like you=E2=80=99re dealing with a compi=
led module that
>> you
>> > can=E2=80=99t edit. Run the same fix for short tags on the library.
>> >
>> > All valid options. Doesn't change the fact that it's more code to upda=
te
>> meaning more time required to prepare for the upgrade.
>>
>>
>> > > I don't trust mass find/replace tools like php-cs-fixer. Some of our
>> > legacy code is really ugly. Auto-formatting with PhpStorm will break
>> it. I
>> > don't mind using an interactive tool, but that means I have to sit the=
re
>> > and hit Y or N for 6,787 instances. Some of them will probably require
>> me
>> > to actually open the file up and check out the surrounding context as
>> well.
>> > And, what happens if I miss one? I run the risk of code leak.
>> >
>> > If auto formatting =E2=80=98breaks=E2=80=99 your code, you have a bigg=
er problem than
>> > short tags.
>> >
>> > I never said that our code was good. Most of our legacy code isn't eve=
r
>> touched. It's a mess of 10k+ line spaghetti files. It works, and until w=
e
>> are able to replace it, we just leave it alone. Now we are forced to go =
in
>> there and mess with it for something that doesn't even pertain to the
>> functionality of our application.
>>
>> Also, you didn't address the issue of missed instances. There is no way =
to
>> be 100% sure any automated or manual process of replacing the tags will
>> get
>> everything. One of the justifications for this RFC was the possibility o=
f
>> code leak if code with short tags is loaded in an environment that has
>> short tags disabled. We've decided to fix that by making sure that any
>> code
>> with short tags will DEFINITELY leak code. That makes a lot of sense.
>> Eyeballing a diff isn't going to help you find missed instances either.
>>
>>
>> > >
>> > > I think it's great that many of you have code bases that are in pret=
ty
>> > good shape and this change isn't going to have much of an impact on yo=
u.
>> > That's not my case, though. It's not the case for a LOT of people. I'm
>> not
>> > against BC breaks - even major ones - if they are justified. I have ye=
t
>> to
>> > see any good justifications for such a massive BC break.
>> > >
>> > > The fact is that this change WILL prevent a lot of people from being
>> > able to upgrade to 8.0 in a timely manner. Anyone that has to justify
>> > spending time to prepare for an upgrade to people that don't understan=
d
>> the
>> > benefits of the upgrade will have an ever harder time trying to justif=
y
>> the
>> > extra time necessary. I also think you are going to find a good number
>> of
>> > people that will upgrade (or use PHP for the first time) unaware of th=
e
>> > change. They'll attempt to load older code that has short tags in it. =
It
>> > won't work. They'll say "screw it" and use python or node.
>> > > --
>> > > Chase Peeler
>> > > chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>
>> >
>> > It's not that I'm against the idea of abolishing short tags. It's that=
 I
>> don't feel the problems abolishing them will cause are justified by the
>> reasons given for abolishing them. No matter how easy you think it is to
>> deal with this, it won't change the fact that it's going to be a barrier
>> to
>> upgrading for a lot of people. It's going to have a negative impact on 8=
.0
>> adoption. It's going to lead to a larger number of people running PHP
>> versions that have reached EOL. In the end, it's going to hurt the marke=
t
>> share and reputation of PHP.
>>
>>
>>
>> --
>> Chase Peeler
>> chasepeeler@gmail.com
>>
>

--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000001bf514058748e4ec--