Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105409
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>
 <5741936F-B1F4-43C7-B815-F9D8030AC7BB@koalephant.com> <e5c10f59-bde9-dadc-e837-266f870b6358@lsces.co.uk>
 <B392E7C8-BBAC-48D2-BBBA-3D7C7EFD9595@koalephant.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> <CADyq6s+6Gqaa6Werc0Vn=gKWrrqC71+ry1rpsPEpq4BSE4wq_Q@mail.gmail.com>
 <CAPKYkKz4u-D3ebVJCU8TgCuEGVVC28-YSj76sCU1TS4BaDjeBA@mail.gmail.com> <CAAfnsFUAY_O9JbDWMsntFKz1otTjE0BKYrsMif3DzG+zQpahxw@mail.gmail.com>
In-Reply-To: <CAAfnsFUAY_O9JbDWMsntFKz1otTjE0BKYrsMif3DzG+zQpahxw@mail.gmail.com>
Date: Wed, 24 Apr 2019 15:30:32 -0400
Message-ID: <CAPKYkKz9mNpAtBd7oPytoeYFE4kD6_tCUEWZjw3XYvPQD+xBxA@mail.gmail.com>
To: Peter Kokot <peterkokot@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, Christian Schneider <cschneid@cschneid.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e148f405874bbc6c"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000e148f405874bbc6c
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 24, 2019 at 3:07 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello,
>
> On Wed, 24 Apr 2019 at 19:44, Chase Peeler <chasepeeler@gmail.com> wrote:
> >
> > On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com>
> wrote:
> >
> > > On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com
> >
> > > wrote:
> > >
> > > > Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>:
> > > > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, <
> cschneid@cschneid.com
> > > >
> > > > wrote:
> > > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>:
> > > > > > just a friendly reminder that by the time one writes an email
> here
> > > > > > these tags can be already replaced with the usual ones.
> > > > >
> > > > > A friendly reminder that some people are hosting customer code
> which
> > > > they do not want to touch but will get support requests once the code
> > > > breaks.
> > > > >
> > > > > - Chris
> > > > >
> > > > > That's normal? Everyone has projects to maintain, and breaking
> changes
> > > > are common: they're gonna call you for one anyway: if you don't like
> > > that,
> > > > then you are in the wrong line of business.
> > > >
> > > > See Chase Peeler's point: A breaking change should have a reward big
> > > > enough to justify it.
> > > > And that's what where we (including Zeev Suraski and other core
> > > > developers) disagree.
> > > >
> > > > - Chris
> > > >
> > >
> > > Run a fixer: they are out there, and they are extremely stable too.
> > >
> > > Also a good chance to finally take a look at code that has been
> rotting in
> > > a hard drive for too much time.
> > >
> > All of that takes time though. I have 6,787 short opening tags found.
> Even
> > if I use a fixer to generate a diff, or, to fix them and then examine the
> > diff in a pull request... that's going to take a LOT of time. It's going
> to
> > start getting messy if I find false positives and need to exclude
> changes.
> > It still doesn't address the impact of changes that aren't found. Are you
> > 100% positive that the fixers out there will catch EVERY single instance?
> > php-cs-fixer doesn't update <? inside of strings. If that's generating
> > dynamic code, then that's not getting caught.
> >
> > The output from php-cs-fixer just generated a diff file that was 161,000
> > lines long. But yea, that's something I can scan through real quick and
> > make sure nothing is going to get broken. No chance I'll miss something
> > either.
> >
> > I would LOVE to have the time to go through our legacy code and clean out
> > old stuff. We have a lot of technical debt that, while we aren't paying
> it
> > off at the moment, it's gaining any interest either. We also have plenty
> > that is. It's tough to justify putting off the stuff that is gaining
> > interest to focus on stuff that isn't so we can fix short tags.
> >
> > I don't work for a software company. I develop an internal application
> for
> > a non-software company. There are 2 other developers and enough work for
> 10
> > developers. It's going to be VERY hard for me to get management to
> approve
> > putting off projects that have a direct impact on our business in order
> to
> > upgrade to PHP 8 when that time comes. I think you are going to find
> that's
> > a pretty common occurrence, and the adoption rate of PHP 8 is going to be
> > VERY low. Especially when more and more user-friendly alternatives like
> > python and node are coming along. It was one thing when the options were
> > RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
> > going to provide additional user friendly opportunities in the next
> couple
> > of years leading up to PHP8.
> >
> > Can someone PLEASE tell me the positive gains this RFC will accomplish
> that
> > justifies risking:
> > 1.) Losing market share
> > 2.) losing credibility
> > 3.) removing a large number of libraries that are fine from a technical
> > aspect, but will stop working due to the existence of <?
> > 4.) new security risks (code leaks that are more likely than the code
> leaks
> > the RFC seeks to prevent)
> >
> > And, please don't use the existence of code fixers to justify this unless
> > you are willing to demonstrate how it's quick and easy to go through a
> > 161,000 line diff file or are willing to 100% guarantee that the fixer
> will
> > not break anything, will not fix anything it shouldn't, and will not miss
> > anything it should fix.
> >
> >
> >
> >
> >
> > --
> > Chase Peeler
> > chasepeeler@gmail.com
>
> I've done few commits with about 8k files changed with very repeating
> changes like this and without breaking anything. It will take you
> about 30minutes... Let's say, one hour for also taking a break from
> all the scrolling the git diff and to return the merge the next day
> after another check or something like this.
>
> The change (speaking for 8k files using short opening tags converted
> to <?php) itself takes about 80 seconds with using PHP CS Fixer but
> the memory_limit needs to be increased a bit and only relevant change
> is done in all files. 8k (or 6k) opening tags is nothing very big
> actually.
>
> Honestly, the amount of people that have never seen or worked with my
codebase telling me how easy and low risk it will be to make the change are
starting to annoy me.

Can even one of you actually address any of the points I've made about why
the potential negatives of this change far outweigh any potential
positives? Heck, can you even present any potential positives?


> Then also search for similar occurrences by using a regex for those
> edge cases you're mentioning in strings and such (I doubt there are
> but ok) and you have this fixed. Then run this app on PHP 8 and you'll
> see the other BC breaks that happen due to the major release. Major
> releases are meant to break things because otherwise we can only load
> the language with new things and maintain old stuff in there for
> eternity.
>
> As I've said before - I have no issue with BC breaks. What I have an issue
with is a BC break that has a large potential for negative consequences
that aren't anywhere close to being outweighed by the positive ones. None
of the reasons presented in the RFC justify the downsides. Not a single
person has addressed any of the potential negatives being brought up,
either. They just respond that it's easy to update your code and pretend
like there isn't a potential for negative consequences.


> That's why serious apps have support cycles and follow their
> frameworks release and life cycle, and in the end also PHP cycle.
> Simple as that.
>
> I work on an internal application for a non-software company. We are
beholden to the cycles of our business. We try and work in upgrades when
it's possible and we have a lull between major projects or when we can
justify delaying a project in order to perform an upgrade.


> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Unless someone decides to actually discuss the issues I've raised in
previous emails, instead of just telling me how easy it's going to be for
me to update my codebase that they know nothing about, this will be the
last message I'm sending in this thread.


-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000e148f405874bbc6c--