Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105382
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>
In-Reply-To: <301BACB1-86FF-4315-9D99-D17A2FDC7F27@koalephant.com>
Date: Wed, 24 Apr 2019 11:50:50 -0400
Message-ID: <CAPKYkKw6WGNJpGWzzZVkPkNMAmnkO2iUh-Ssmq0w+jHUG4eaAA@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002a4d1f058748abe9"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000002a4d1f058748abe9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 time
> 8.1 is
> > > released.
> >
> >
> > Two characters less than this sentence of yours is a 1-liner find/sed
> 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 control=
 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. Once I=
=E2=80=99m
> not in the middle of anything I=E2=80=99ll review it again and then merge=
 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 part =
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 with
'<?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 <? i=
s
> 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 use i=
t
> in 8.0 is a barrier to me upgrading.
> >
>
> You do the same thing as if the library had a security issue or some othe=
r
> 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 compiled=
 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 update
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 there
> 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 wel=
l.
> 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 bigger =
problem than
> short tags.
>
> I never said that our code was good. Most of our legacy code isn't ever
touched. It's a mess of 10k+ line spaghetti files. It works, and until we
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 of
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 pretty
> good shape and this change isn't going to have much of an impact on you.
> That's not my case, though. It's not the case for a LOT of people. I'm no=
t
> against BC breaks - even major ones - if they are justified. I have yet t=
o
> 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 understand t=
he
> benefits of the upgrade will have an ever harder time trying to justify t=
he
> 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 the
> 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 market
share and reputation of PHP.



--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000002a4d1f058748abe9--