Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105412 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47450 invoked from network); 25 Apr 2019 00:01:50 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 25 Apr 2019 00:01:50 -0000 To: internals@lists.php.net References: <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> <599449fa-0961-8d7f-07a7-2d463a5e56b1@telia.com> Date: Wed, 24 Apr 2019 22:02:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <599449fa-0961-8d7f-07a7-2d463a5e56b1@telia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Posted-By: 94.0.205.114 Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags From: markyr@gmail.com (Mark Randall) Message-ID: On 24/04/2019 21:32, Björn Larsson wrote: > With that experience in mind I wonder how different libraries will fare, > given this > change? One should also have in mind that there has been a discussion on > this list about extending the support cycle for PHP 7.4 like for 5.6, but to > some degree it was rejected which doesn't help migration efforts. I'm sure Nikita will pop up sometime in the next few days and put his recently downloaded 1000+ packages through his parser and give us some figures on how many use short open tags, if he hasn't already done so. I would naturally expect it to be extremely small, after all it makes no sense to have a public package which requires a language feature to be enabled in the INI and which can't be relied upon. If there's a problem, it will almost certainly be with internal code, which naturally there's a few million times more of, but that seems very much in-scope for individual developers to fix if they want to upgrade to PHP 8. My main worry is, and remains, that it's being converted to just a "not parser significant" in PHP 8. The potential for unexpected data / code leaks is *significant*. Until someone can convince me otherwise, I will continue to strongly believe that