Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105413 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51619 invoked from network); 25 Apr 2019 00:11:22 -0000 Received: from unknown (HELO v-smtpout1.han.skanova.net) (81.236.60.154) by pb1.pair.com with SMTP; 25 Apr 2019 00:11:22 -0000 Received: from [192.168.7.8] ([213.64.245.126]) by cmsmtp with ESMTPA id JPBUhLPTqSq0xJPBUhXPNT; Wed, 24 Apr 2019 23:12:05 +0200 To: Chase Peeler , Marco Pivetta Cc: Christian Schneider , Peter Kokot , PHP Internals List References: <06473788-a34b-f041-36e6-31d19d8dda4c@cubiclesoft.com> <59cafbfb-2bb0-468c-458f-74bcac780e0f@korulczyk.pl> <004c01d4f09f$880ac320$98204960$@roze.lv> <004401d4faa3$60f83700$22e8a500$@gmail.com> <2f922f17-bc7c-313a-8f77-122e861995be@lsces.co.uk> <5741936F-B1F4-43C7-B815-F9D8030AC7BB@koalephant.com> <49A4B76C-4C62-4CBE-BA20-FBE56CA29AB0@cschneid.com> <609E93CF-099B-446C-AD28-04F1D802C9F0@cschneid.com> Message-ID: <48c67f2b-02f1-510a-320f-99f67215ad14@telia.com> Date: Wed, 24 Apr 2019 23:12:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfABLf2j0wTuoikr8ercHQ/FHP28aN7zgXOCUcV2cICTkEje5BMUHrWdge5UvfgVsAlDCUlHZb3arfd57hz0ONMCTfPzXClYCUxFUqIFJYRX0S+VnrE3K gni7vOkkDDOyI19Txgd6ZhP6T/dQ7/j8b5k9njt2lRVQ9Kh872wHd1as5uct+MzKYVhKVNz16ozgG1P0/CU8/5WETZi9Lnk6JUCV5tAbqsjxD5G1flW6PnK9 NIHOGsAsPRoZa/OIMngy2F5dzbLtgJdAX1LRwlXqYgUWTLF2AWUca/5BI43XsHU7jJLkMzWZoykmVJoP6AQozg== Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=) Den 2019-04-24 kl. 19:43, skrev Chase Peeler: > On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta wrote: > >> On Wed, 24 Apr 2019, 19:25 Christian Schneider, >> wrote: >> >>> Am 24.04.2019 um 19:13 schrieb Marco Pivetta : >>>> On Wed, 24 Apr 2019, 19:10 Christian Schneider, >> wrote: >>>> Am 24.04.2019 um 19:01 schrieb Peter Kokot : >>>>> 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 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) Hi, I did a quick check on two open source libraries that I'm using, namely Smarty templating library and Revive ad server. A quick glance at hand shows that they both uses the